Re: Questions about "Imendio's Vision on Gtk+"

[Alexander Larsson <alexl redhat com>]

On Fri, 2008-03-14 at 16:30 +0100, Tommi Komulainen wrote:
> 2008/3/14 Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>:
> >
> > 3) Exposing struct fields in GObject class structs? How else would one
> > override methods? By calling a designated
> > g_object_class_override_method(class, method, new_method); or something of
> > the sort?
> 
> My thought has been that you could use a struct of function pointers,
> including the ABI version number and the size within the struct and
> pass that struct pointer to a g_object_class_override_methods()
> function. I believe this is similar to what COM does and would allow
> backwards compatible implementation, however ugly it would turn out to
> be.
> 
> However I think the idea was to continue exposing function pointers in
> class structs and just add $ENOUGH extra slots for future expansion.

Yeah. Function pointers like that don't have the issue that data in the
object structs have, namely that user code reads/write them and you
don't get called when this happens (which means you can't emulate them
for backwards compat). Furthermore, these pointers are only written at
class construction time and not accessed by consumers of the class.

In general we don't want to go crazy banning all structure elements
without thinking, we just want to make it possible to maintain backwards
compat when changing the implementation.