Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upUse a dedicated Angle type for angles instead of Length<Rad>. #243
Conversation
|
r? @kvark |
|
looks sensible |
|
@bors-servo r+ |
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 7, 2017
Use a dedicated Angle type for angles instead of Length<Rad>. This is the other breaking change that I want to sneak in @SimonSapin's bump. Length has proved quite unergonomic for angles. We don't have a good use case for storing angles in degrees (that would be evil), and there could be a lot useful specific methods for methods that apply for angles but not lengths. With a dedicated angle type we can write things like: ```rust mat.pre_rotate(Angle::radians(PI)); mat.pre_rotate(Angle::degrees(90.0)); ``` which deals with degrees in a nicer way (everything is always stored in radians but conversion to and from is easy). Also, with Angle we can implement `Angle<T> / Angle<T> = T` to compute ratios, multiply angles by these ratios, etc. I ran into the (lack of) ergonomics with `Length<Rad>` a lot in the SVG logic in lyon. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/euclid/243) <!-- Reviewable:end -->
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 8, 2017
Implement Neg for Angle. I forgot to implement Neg in #243. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/euclid/246) <!-- Reviewable:end -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
nical commentedDec 7, 2017
•
edited by larsbergstrom
This is the other breaking change that I want to sneak in @SimonSapin's bump.
Length has proved quite unergonomic for angles. We don't have a good use case for storing angles in degrees (that would be evil), and there could be a lot useful specific methods for methods that apply for angles but not lengths.
With a dedicated angle type we can write things like:
which deals with degrees in a nicer way (everything is always stored in radians but conversion to and from is easy).
Also, with Angle we can implement
Angle<T> / Angle<T> = Tto compute ratios, multiply angles by these ratios, etc.I ran into the (lack of) ergonomics with
Length<Rad>a lot in the SVG logic in lyon.This change is