hi, Felipe Contreras schrieb: > On Tue, Jun 3, 2008 at 3:23 PM, Tim Janik <[EMAIL PROTECTED]> wrote: >> 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. > > So how should people create extra functionality? For example, I > extended GHashTable creating a g_hash_table_peek_first function, for > which I needed the private fields. So I had to create fake structures > with the same fields just to access them. I know that's dirty, but it > works, and creating my own hash table just to add that function wasn't > appealing. > > What about publicly stating that including foo_private.h is looking > for trouble, and perhaps foo_protected.h for objects that inherit. > > I'm just dumping ideas, I don't know what's the proper solution, but I > definitely see obstacles to re-use current objects/widgets. > > Best regards. >
The proper solution in the above case is to submit a patch that adds g_hash_table_peek_first to the GHashtable :) Stefan _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
