You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I chose the range 0 to 255 for the red, green, and blue fields since that was pretty common but also made them floating point so they could represent a large number of colors. Floating point numbers work better with the rest of the crate since users often use f64 to represent other values in their program for methods like forward, right, etc.
The thing is, most libraries that use 255 as the upper bound for their color ranges do so because they're using u8 to represent the value of that field. 0 to 255 is the valid range for the u8 type. Given that we're using f64 for those fields anyway, it might actually make sense to change the range to something like 0.0 to 1.0 or maybe 0.0 to 100.0 instead.
This is a good candidate for a pre-1.0 change since this is definitely a breaking change.
Any thoughts on what we should do here are welcome. This is probably one of the largest changes I've thought about making to the library. The color type has been there since the very beginning, so there is a lot of code depending on it.
The text was updated successfully, but these errors were encountered:
When I originally wrote this crate 4 years ago (wow time flies!), I defined a type to represent colors:
turtle/src/color.rs
Lines 211 to 221 in 55ee9c0
I chose the range 0 to 255 for the
red
,green
, andblue
fields since that was pretty common but also made them floating point so they could represent a large number of colors. Floating point numbers work better with the rest of the crate since users often usef64
to represent other values in their program for methods likeforward
,right
, etc.The thing is, most libraries that use 255 as the upper bound for their color ranges do so because they're using
u8
to represent the value of that field. 0 to 255 is the valid range for theu8
type. Given that we're usingf64
for those fields anyway, it might actually make sense to change the range to something like 0.0 to 1.0 or maybe 0.0 to 100.0 instead.This is a good candidate for a pre-1.0 change since this is definitely a breaking change.
Any thoughts on what we should do here are welcome. This is probably one of the largest changes I've thought about making to the library. The color type has been there since the very beginning, so there is a lot of code depending on it.
The text was updated successfully, but these errors were encountered: