Re: Subclassing in Gtk+ 3.0

["A. Walton" <awalton gnome org>]

2009/12/8 David Nečas <yeti physics muni cz>:
> On Mon, Dec 07, 2009 at 04:17:40PM -0200, Tristan Van Berkom wrote:
>> 2009/12/7 David Nečas <yeti physics muni cz>:
>> >
>> > 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 gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list