On 18.04.2013 23:44, Duncan Gibson wrote: > I saw the other comment in the docs about type() that it was a > hold over from the Forms implementation.
Please ignore Forms compatibility. We're going to remove this, and AFAICT Matt has removed everything Forms related in FLTK 3.0. > I was struggling to relate > different uses of type() in different parts of the library to one > consistent whole There is no consistent whole, it's always only used consistently in one (part of the) widget hierarchy, as written elsewhere. > but it never occurred to me that I might not need > to use type at all. I believe that you don't need such things like type() in a widget hierarchy if you design everything "correctly" (in the OOP sense), maybe with virtual methods and such. However, in (FLTK) practice we can see that the base class often has a draw() method that must know which derived classes may exist, and for which one of these it is called in /this/ instance of an object. This can lead to such problems as we can see in this thread. > I suppose that if you are creating a new hierarchy of widgets then > you are free to implement RTTI within those widgets in any way you > want, as long as you respect the existing use of type(). True. > So would current developer advice be to implement local RTTI ? I don't know. > Or should we be looking at more modern "template" or "prototype" > classes where implementation is passed in? [I'm not sure if I'm > using the GoF Design Pattern nomenclature correcty here]. Do it as fits best, I guess. A moderate use of type() within a new class hierarchy may be okay, but adding classes to the Fl_Valuator hierarchy (with pseudo RTTI via type()) might result in problems. Maybe. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
