> Generally I feel that a typedef is sufficient. It does not prevent > misuse, but it makes the function prototypes clear. It also means that > the user can type 0xaarrggbb directly into the code and it works. Qt is > really annoying that I always have to look up the converter function.
I disagree. I use Color, Point, Rect, etc. types extensively and they're so much more pleasant to work with that I convert to and from the low level fltk (x, y, w, h) stuff at the boundaries and use them exclusively in my code. The benefit is even greater with complex types like Rect which have canonical forms, invariants, etc. I wouldn't want to type a hex value directly in the code and have it implicitly converted into a color, I like the clarity of e.g. Color.rgb(uchar, uchar, uchar) and Color.rgb(double, double, double), Color.rgba(...), or even 'c2 = Color.rgb(..); c2 = c1.a(0.5)'. When I print them out for debugging, I would rather see 'Color.rgb(1, 2, 3)' than some giant decimal number, and the benefit is multiplied when printing out complex types with color components. And of course the convenience of c.brightness(1.2) or c.is_opaque() or whatever else. Trading all that and type safety for the ability to use hex literals seems like, well, not a very good trade. And it's not even a trade, you can get the hex literal to color conversion and back by adding a implicit conversion constructors, but there's a reason those are pretty much universally discouraged: they have all the implicit conversion disadvantages of a typedef. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
