matthiasm wrote:
> ...
> 1: the advantage of using name spaces apart from naming conflicts can be 
> less typing. For example:

"using" doesn't work well when you have multiple namespaces (think
Boost and other C++ libraries that use namespaces), and it can be
*more* confusing than a prefixed name (which is why most C++ books
recommend against "using" in application code...)

> 2: there is much more to the new API than the new namespace. Widgets are 
> named much more consistently (Fl_Tabs became TabGroup, Fl_Pack became 
> PackGroup to indicate that they are groups, etc. etc.). FLTK2 sticks 
> with one single naming scheme (almost) all the way through to keep the 
> interface easy to understand.

Sane renaming of classes doesn't require namespaces:

"Fl_Tabs.H":

     #include "Fl_TabGroup.H"
     typedef Fl_TabGroup Fl_Tabs

> 3: there are are few logical changes modifying inheritance. Fl_Image, 
> Dymbols (you know, the @circle stuff), and boxtypes are now derived from 
> the same base class, so where ever you can use a box in FLTK1 ow, you 
> can just as well use a collection of images, and wherever you insert 
> symbols into a label, you can now insert an image as well. That is 
> really neat for prepending a little icon in front of a Browser entry.

Again, this doesn't require namespaces to make the change.

...

Early "versions" of FLTK 2.0 retained the old Fl_ prefix and still
managed to implement many of the changes that are in 2.0.  When Bill
made the namespace change, it took months and destroyed all traces
of 1.x compatibility forever.  (The compatibility headers that were
added later never provided enough to be usable...)

Now, I'll grant that we can't provide 100% compatibility when adding
features to FLTK, but at the same time if we can minimize the number
of API changes we'll ensure the best changes of adoption by existing
developers - just compare the number of applications on the links
page that are FLTK 1 based compared to FLTK 2 apps...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to