2009/12/8 David Nečas <yeti@xxxxxxxxxxxxxxx>: > On Mon, Dec 07, 2009 at 04:17:40PM -0200, Tristan Van Berkom wrote: >> 2009/12/7 David Nečas <yeti@xxxxxxxxxxxxxxx>: >> > >> > Hello, how is subclassing intended to work in Gtk+ 3.0? >> > ... >> >> Currently in preparation for 3.0, all structure members are getting accessors >> so that subclasses can continue to access the data, I'm not sure whats the >> ultimate plan with GSEAL(), if the data will migrate to private structures or >> not. > > I wonder what is the ultimate plan, and generally what is the best > approach to GObject encapsulation, as I need to do it for some my > libraries. > > 1. Make object structs private: > + good encapsulation > + simple > + all object data in the same memory block > + no overhead > - cannot subclass (a big minus) > > 2. Have no data members at all and use g_type_class_add_private()/ > /G_TYPE_INSTANCE_GET_PRIVATE() for everything: > + good encapsulation > + all object data in the same memory block (at least that's what > the docs say) > - big run-time overhead in getting the private data for all method > calls[*] > - code littered by the private data acquisition > > 3. Add exactly one pointer MyFooPrivate as the object struct data member > and put all the object data there: > + good encapsulation > + small overhead > - object data scattered in memory > - code somewhat uglified by the indirection (not as bad as in 2) > > 4. Use some sealing mechanism similar to GSEAL and left at least one > reserved pointer for future private data (as in 3): > + no overhead > + object data generally in the same memory block > ? unclear encapsulation (may tempt people to access the data members) > - can replace fields only with fields of the same size and alignment > when the data members need to change > > Are there other possibilities? You can do something like a mix of 2, 3, and 4: * GSEAL() bridges the gap between 2.9x.x and 3.0 by making it easier to port and see where we're missing accessors. * Widgets are patched during the 3.0 ABI break so their currently public struct members are moved to GtkFooPrivate. * g_type_class_add_private() the GtkFooPrivate struct to prevent some fragmentation. * Add a GtkFooPrivate* to the object's public struct, populate it during gtk_foo_init() with a single G_TYPE_INSTANCE_GET_PRIVATE() call to speed up access and prevent duplicate GtkFooPrivate *priv = G_TYPE_INSTANCE_... lines. + roughly as fast as before, low memory overhead + code is future-proof and much easier to maintain with proper encapsulation - accessors are now mandatory, even for subclasses - code's a bit more ugly (when implementing a widget, 'widget->foo' is now 'widget->priv->foo'). AFAIK this is the 'state of the art' way to write new GObjects, and it's been the way I've been coding for a while (out of habit). I believe this is also the way that Vala currently outputs objects. -A. Walton > All approaches the have disadvantages, for me 3 seems to have > disadvantages I can live with but since Gtk+ somehow sets the standard > it would be good to know where the encapsulation is heading in Gtk+. > > Yeti > > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > http://mail.gnome.org/mailman/listinfo/gtk-list _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
