On 9/27/05, Adam Badura <abadura@o2.pl> wrote:
But this in deed does have some disadvantages. Previous I had functions like
component_type component(const int index) const; component_type& component(const int index);
or simple [] operator for getting components. This allows to easy write code which preforms the same operation on each color component (for example interpolates color by interpolating R than G than B...). Now (when components could have different types) writing such a function is almost impossible because you must return one specific type (inheritance is imposibble due to speed overhead and use of basic types).
I don't see this as a big loss. It's still easy to write code which does the same thing to each component, you just have to do it explicitly with three separate calls instead of a loop. I don't think you should be restricting the functionality of the library this much (since it sounds like components with different types will be a relatively common case) just to avoid the minor inconvenience of not being able to be generic over components. In any event, the color models in which it makes sense to have different types for the different components are probably models in which it doesn't make sense to perform the same operation on all three components. Performing the exact same operation on all three components only really makes sense in RGB, CYM, and their close relatives, which model colors as mixtures of semi-arbitrary primaries; it's not something you're likely to want to do in HSV, LAB, etc, where the different components are conceptually distinct concepts. So, it seems like an ideal design would be to allow color classes to specialize depending on whether their components are in some sense equivalent. Those that are could offer a component() method, and would require the same type for all 3 components. Those that aren't would not offer a component() method, and consequently would have the freedom to use different types for the different components.