On 18.04.2013 18:52, Greg Ercolano wrote:
> I usually try to avoid type(), because while looking at
> FLTK's own code, I've seen coding techniques that disagree
> with the above, namely:
>
> Fl.cxx: if (w->type()>=FL_WINDOW) {dx -= w->x(); dy -= w->y();}
> Fl.cxx: if (p->type() >= FL_WINDOW) break; // don't do the unmap
> Fl.cxx: if (type() < FL_WINDOW) {
> Fl.cxx: while (wi->type() < FL_WINDOW) {
> Fl_Group.cxx: if (o->type() < FL_WINDOW) return o->handle(event);
> Fl_Group.cxx: if (type() < FL_WINDOW) {p[0] = x(); p[2] = y();} else {p[0]
> = p[2] = 0;}
> Fl_Group.cxx: if (type() < FL_WINDOW) {
> Fl_Group.cxx: if (type() >= FL_WINDOW) dx = dy = 0;
>
> In this case, FL_WINDOW is defined as 0xf0, and the comment
> from FL/Fl_Window.H says:
>
> ../FL/Fl_Window.H:#define FL_WINDOW 0xF0 ///< window type id
> all subclasses have type() >= this
>
> So it sounds like you can do whatever you want.. but only
> with the low order 4 bits if type().
That's not entirely correct, for some interpretation of "correct".
0xF0 means decimal 240, so there's a bunch of 240 values (0-239)
you can use, whereas "only with the low order 4 bits" seems to assume
only 15 distinct values. However, it is correct that you can only use
4 bits if you want to base your type() distinction on something like
a bit mask - then you can only use 4 bits.
> type() is actually one of those things I try not to mess with
> in favor of using my own type() in my derived classes because of
> the above.
Do you mean type() literally, or does it stand for a differently named,
but similar method? I would not recommend to overload type() in a way
that it uses another member variable in a derived class. Although it
is possible, it could lead to some confusion. And since the FLTK core
makes use of type() for some decisions, it must be clear that FLTK
always uses Fl_Widget::type(), whereas your class would always have
to make sure that it uses YourClass::type(), i.e. you can't use a
(Fl_Widget *) pointer and use type() with this (because it's not
virtual, but this is so by design).
> And when you derive from a base class that has decided to make
> use of type() a certain way, you're kinda bound to the parameters
> of its use in your derived class.
True.
> I usually try to make my own 'flags' variable in my class,
> and make methods that manipulate it, rather than overload type().
Ah, okay, I should have read this before I wrote my comments above. ;-)
> I guess you could override type() with your own, and manage a
> "uchar type_" in your derived class so that the user can use type()
> on your class without affecting the base class.
See above, I wouldn't do this.
>> Therefore, are there general guidelines on type(), or do they only
>> apply on widget-by-widget basis?
>
> I have a feeling the design is "read the source luke";
> look at how the widget you derive from is implemented,
> (i.e. how it makes use of type()) and then design your work
> as an extension of that implementation.
>
> As much as object oriented programming tries to make a black box
> so that one shouldn't have to be concerned with implementation
> internals, when deriving classes you kinda have to.
Yep, unless all is documented so well that you don't need to. You
can't access the source code for libraries you don't get as sources,
for instance. And who would try to read the sources of system libs,
or X11, for instance.
> In fltk it's often important for instance how base classes
> implement handle(), as often your derived class has to take
> the base class's implementation of handle() into account
> to keep the code details in sync.
>
> I try to compare the code implementation with the docs
> to see what the general philosophy is, and then try to design
> along a line between the two. I try to get as intimate as
> possible with the implementation of the base class, so the
> derived widget becomes an extension not only in function
> but implementation as well.
Theoretically you shouldn't even *try* to know how it is implemented,
because one OOP principle is that implementation can change, as long
as the interface is kept stable, but in practice ... (you said it).
Albrecht
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
