Hi PeterB, > That does seem like a good idea. I imagine that the definite release would > go > into a maintenance cycle as the stable version while the internals get > butchered during the redesign?
Yes, the definite release would go into extended maintenance mode while the development version gets modified. However, based on what I have been reading over the past few days, all of the proposed and/or in progress changes made by various people seem quite radical, so I encourage those people who want to make really radical changes to fork and rename their implementation as it will be difficult to integrate the huge architectural changes into the existing code base. The only way I will accept radical changes is through a set of controlled small step refactoring stages (like what was done with the glist branch and the currently ongoing noscreen). > > Also, my arguments against gobject are looking sillier by the minute, as I > realize that gobject was **designed** to make language bindings easy to > write... d'oh! > I've been looking at the whole gobject mechanism for a while now. Every time I look at it, I cringe since all the things that are so easy in C++ are so much harder (and verbose) using the gobject API. Of course, the whole easy language binding and that you stay with portable C are certainly advantages, but do those outweigh the ease of maintenance of the code (IMHO C++ is easy to maintain if it is written correctly and cleanly)? -Ales _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
