On Tue, 3 Jun 2008, Alberto Mardegan wrote: > ext Kristian Rietveld wrote: >> 10. Remove all structure fields from the public API. There are two ways >> this can be done: >> a) Move object structures to private headers. >> b) Move object structures to the local C file, the rest of GTK+ will then >> also have to use accessors. > > If you go for (a), will the private headers be installed in the target > system?
No, definitely not. "private headers" here means "internal", in that they'll be accessible only from within the Gtk+ source tree during the gdk and gtk library builds. > I've often felt that subclassing a GTK+ widget to modify its > functionality is usually harder than creating a new widget from scratch > (copying from the GTK+ code), as accessing the parent private members is > impossible, and many members that could be useful for a derived class > are in the private struct. > > I like the Python way of doing it (by mangling the members name you want > to protect, so the client must really know what he's doing when > accessing it); I would find it useful if private GTK+ were private but > somehow accessible (at least from derived classes). This would essentially make the fields part of our (semi-)public API, and that in turn means we need to preserve their behaviour compatibly. This is something we cannot provide and which gets us into much trouble currently when we try to fix bugs or optimize/improve the current code base. However, if instead the public API is defined only in terms of function entry points (object properties and signals are essentially provided via functions as well): - We can add compatibility code to those functions to emulate old behaviour on top of a changed code base. - We can establish a clear migration procedure for any particular feature by adding new functions and deprecating old ones. - We can provide compile time and runtime warnings for deprecated functions to aid developers in migration. > Ciao, > Alberto --- ciaoTJ _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
