-
Notifications
You must be signed in to change notification settings - Fork 21
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
for Julia 0.4: rename to Colors, rename ColorValue => Color #56
Comments
👍 We should also think about what to do with module Colors
abstract Color
abstract BasicColor <: Color
immutable RGB <: BasicColor
...
immutable AlphaColor{T} <: Color
...
end |
Would it be a horrible idea to just have alpha values everywhere? |
You'll get into trouble that way if you're trying to pass a 3-component color array to C or if you're |
Not if the type of the Alpha component is |
Or I guess a better choice would be a zero-field immutable whose numeric value is always one. |
It makes me a little uncomfortable to have the graphics part of this package encroach on the colorimetry part by making color inseparable from alpha values. But that's a superficial objection. If the alpha value could be "hidden" with an empty immutable it could work. |
I think your gut instinct may be right, @dcjones – it was just a thought. |
@dcjones Yes, alpha values don’t make much sense in terms of pure colorimetry because it would change the color coordinate depending on the background the color+alpha would be mixed with. |
Given #57, it occurs to me that perhaps |
The other potentially breaking change that's been brought up a few times is generalizing I suppose we could do this by parameterizing @m-lohmann, @glenn-sweeney, @rennis250 let me know if you have an opinion on how this should look. |
I don't really have a dog in this fight, so take this with a grain of salt... but I'm wondering at what point things become over-parametrized, and it wouldn't just be easier to have separate types. This may not be true here, but in this case, I'm curious what benefit a parametrized RGB type offers? |
My gut reaction is that we should continue with a type per colorspace rather than handling some cases with parameters. |
And now that we have |
I agree with @JeffBezanson. Best, |
Also, should it be Colors.jl or Colours.jl? :P |
Farben.jl |
I don't think this disruptive change would be warranted now, but since 0.4 is going to be a watershed release anyway, it might be a good time to shift names about a bit and this one has been bugging me for a while. The plural package name thing is becoming a bit of a convention in Julia packages.
The text was updated successfully, but these errors were encountered: