Re: Subclassing in Gtk+ 3.0

[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?

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


[*] Yes, I benchmarked it.