fponticelli
commented
11 years ago To be honest I really think it is correct this way. You can use Hsla in place of Hsl because it has all the information required by Hsl. You cannot do the reverse because the alpha channel is unknown and assuming a default in this case doesn't sound right. Subclassing is specialization, and Hsla is definitely more specialized than Hsl. Something to consider is to not have the alpha channel entirely or ust to have a flat hierarchy where alpha is also present. What I don't like of the second is that it adds unused information (particularly for Rgb8) for most cases.
On Mon, Dec 31, 2012 at 2:40 AM, Zachary Dremann notifications@github.comwrote:
Shouldn't inheritance of alpha classes be reversed: e.g. Hsl should inherit from Hsla. It sounds counter-intuitive, but I think it is the proper way to do things.
If a user asks for an Hsl, but they get an Hsla (a subclass of Hsl) what is the expected behavior? To ignore the alpha portion would violate the Liskov Substitution Principle.
Instead, if Hsl inherited from Hsla, Hsl could be thought of as a special case of Hsla that is always 100% opaque. If a user asks for an Hsl, they cannot get an Hsla, and if they ask for an Hsla, they will be prepared to handle an Hsl, because it is simply an Hsla with full opacity.
— Reply to this email directly or view it on GitHubhttps://github.com/fponticelli/thx.color/issues/2.
Shouldn't inheritance of alpha classes be reversed: e.g. Hsl should inherit from Hsla. It sounds counter-intuitive, but I think it is the proper way to do things.
If a user asks for an Hsl, but they get an Hsla (a subclass of Hsl) what is the expected behavior? To ignore the alpha portion would violate the Liskov Substitution Principle.
Instead, if Hsl inherited from Hsla, Hsl could be thought of as a special case of Hsla that is always 100% opaque. If a user asks for an Hsl, they cannot get an Hsla, and if they ask for an Hsla, they will be prepared to handle an Hsl, because it is simply an Hsla with full opacity.