New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #5388. Made Vector2 angle methods consistent #5428
Conversation
This heavily breaks backwards compatibility, so I don't think this will get merged. |
Well, there are 2 different points on the PR. Point 1. is a matter of fixing a wrong implementation which I think comes as top priority over backwards compatibility (otherwise the only alternative solution is to change the javadocs to reflect what it actually does, mark it as deprecated and create a new one that is consistent with the rest of methods which are counter-clockwise). Or do we just ignore it's wrong? Regarding 2. it does break backwards compatibility and it may be argued that for not a good enough reason, but not "heavily". There will be some cases in which it does break something but it won't in the majority of cases as angles are usually dealt with correctly no matter the range. If the PR is not being merged due to point 2. I'm happy to remove it and keep only 1. |
I would recommend just clarifying JavaDocs to the actual behavior. |
I assume you've read #5388. If we just change the javadocs (and do not deprecate them and create new consistent ones) we would be validating/embracing a bad API and giving up on improving it. Both approaches (breaking backwards compatibility or deprecation) are valid and acceptable depending on the case, taking shortcuts isn't. |
Hm, my two cents on this issue: I thinks, in general, it makes sense to fix to fix these inconsistencies. However, to make it more obvious that something changed with the angle methods, I vote for renaming them to angleDeg(), as suggested in one of the initial issues. This way, the overall naming is more consistent and only |
I think it's a good suggestion @crykn. By renaming them to |
How about keeping the old methods and deprecating them for a few versions (then delete)? The price is very low and it would be a good opportunity to update the javadocs of the old methods to mention that the replacements have a different behavior. |
@Darkyenus now that libgdx is going to have more frequent releases sounds a very good idea, indeed. |
@crykn @Darkyenus I've added new methods with "deg" suffix, deprecated the old ones and added javadocs were required. To make it consistent I've done it for all degrees-based methods (not only |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think deprecating rotate90 (int dir)
is needed, but I don't mind.
It's just an unnecessary method |
I am also against deprecating |
I don't agree with your point, I don't think it makes sense to accept this extra computational cost and lack of precision for any other rotation except for 90º (if that's critical for an app it should implement higher precision logic on their end). But from the thumbs up votes I guess most of you are in favout of keeping it so I go with the majority. My question before making the change is, if this method is useful for the API, shall we rename it to something that is degrees or radians independent for consistency (like |
Why break existing code over something that works well? I would keep the name as it is, 90 in context of rotations is self explanatory. |
Requested change made |
Fix #5388 and #5385.
This PR contains two different changes to Vector2 angle methods:
angle(Vector2)
andangleRad(Vector2)
to return counter-clockwise angles as specified in their javadocs.angle(Vector2)
consistent toangle()
to return values in the [0, 360) range.