On 17.04.2010, at 00:07, manolo gouy wrote: >> >> On 16.04.2010, at 22:19, [email protected] wrote: >> >>> Author: manolo >>> Date: 2010-04-16 13:19:09 -0700 (Fri, 16 Apr 2010) >>> New Revision: 7520 >>> Log: >>> Improved the hierarchy of Fl_Device subclasses to allow separation of = >> platform-specific devices. >>> This introduces multiple inheritance. >> >> Oh no. I was too late answering to the original question. I am no fan >> at all of multiple inheritance. It regularly leads to chaos thanks to >> unexpected name resolution and internal pointer offsets when >> unexpectedly casting. My that's ust my opinion.
I agree with Matthias, although I am personally also using multiple inheritance in special cases. But here, deep in the FLTK core, I would not like to have it, because it would make things difficult to use and to extend. >> Unfortunately the last commit was so huge that I did not see how and >> why the multiple inheritance was introduced. Manolo, could you please >> explain what you changed and why? >> >> Thanks, >> >> - Matthias= > > OK. I certainly don't want to bring chaos. If it's bad, we can go > backwards. Yes, I'm sorry to say that, but I suggest to revert the changes as soon as possible, before others commit other changes, and we would get even more trouble. We should discuss the further proceedings *before* changing the object hierarchy in such an essential (and if it would stay: probably irrevertible) way. > The why is briefly explained in my other post "New hierarchy of > Fl_Device subclasses". > > The new hierarchy is : > > Fl_Device (all present and future devices) > Fl_Graphics_Device (Quartz, GDI, or Xlib depending on the platform) > Fl_Display_Device (above graphics system applied to display) > Fl_Printer (above graphics system applied to printing) > (Fl_Clipboard_Device -- would come here if it's adopted) > Fl_PS_Device (PostScript backend) > Fl_PSfile_Device (PostScript used in printing) > > > Fl_Abstract_Printer (a page-structured device) > Fl_Printer (a page-structured printing device) > Fl_PSfile_Device (a page-structured output sent to a local file) > > Thus, two classes have double inheritance. > Fl_Printer inherits its drawing capabilities from Fl_Graphics_Device, > and its page structuration from Fl_Abstract_Printer. > Similar thing for Fl_PSfile_Device. This could (probably) also be achieved by Fl_Printer *utilizing* one of many Fl_*_device classes. This is already there... > Under Xlib, the hierarchy is a little changed: Fl_Printer is a subclass > of Fl_PSfile_Device (it's exactly the same platform difference > as in the previous device hierarchy). That (the different object hierarchy on different platforms) is also something that I feel *very* uneasy about. It starts with having no clear documentation of the hierarchy (because it's different on other platforms), faking something with "#ifdef FL_DOXYGEN", and so on. > So, there is a single instance > of double inheritance, for class Fl_PSfile_Device. > > This is the only solution I found so that the same > Fl_Device::xxx() Quartz (or GDI) drawing function can be used both > by printing and by display-drawing classes. > > Being on not page-structured is independant from using the > PostScript, Quartz, or GDI graphics backend. So, I see multiple > inheritance as very natural and pertinent here. Not, if there are better ways. When we discussed adding the Fl_Printer class we didn't want to touch the FLTK core. Then we did some minor changes, then we decided to add the Fl_Device layer. Okay so far. But before doing other major changes, we should really discuss them, get consensus, and maybe try them first in a development branch. We also decided, not to do other essential changes in the internal structures before releasing 1.3. We should stay with this decision, unless we find that we get real troubles. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
