Re: g_object_ref_sink and GUnowned

[Torsten Schoenfeld <kaffeetisch gmx de>]

On Tue, 2006-01-03 at 14:32 +0100, Tim Janik wrote:

> >>    GtkObject derives from GUnowned
> >
> > This breaks the Perl bindings of GTK+.
> >
> > Our GTK+ bindings register GtkObject with our GLib bindings at start up.
> > This involves associating it with the namespace Gtk2::Object and it
> > usually also means setting up inheritance so that Gtk2::Object is a
> > Glib::Object.  For that, the GLib bindings look at the parent of the
> 
> hm, why don't your bindings register with unknown types on demand? do
> you have to manually bind every type and make a new release before it
> or anything (already known) depending on it can be used?

We specify the GType to package name mapping manually.  Until we add a
corresponding entry to the mappings, an object with an unknown GType
will be represented as an object of the earliest known type found in the
ancestry.  So if our bindings stumble upon an object of type
GInitiallyUnowned, they will happily represent it as a GObject.

The situation is completely different when we talk about inheritance.
That's where we just consider the direct parent.  This is where we
break.  When trying to set up inheritance for GtkObject, the bindings
call g_type_parent which now returns the GType for GInitiallyUnowned.
This is not known to us so the Perl package for GtkObject ends up not
inheriting from anything while it should inherit from the package for
GObject.

So, we don't break if a new "leaf" type is introduced.  We break if a
previously known type suddenly has an unknown parent.

> > Now, you could argue that our bindings should really walk up the whole
> > ancestry until something known is reached instead of just looking at the
> > direct parent.  And I would probably agree; this has caused us problems
> > in a different context as well.
> 
> i'd even expect future breakage if you don't change your current logic,
> e.g. pointer or boxed types could be made deep-derivable and then the
> imemdiate ancestor of boxed types in gdk/gtk may also change.

After some discussion on IRC, it turns out that I was actually wrong
when I said that we could just walk up the ancestry to fix the problem.
muppet gave this example: Consider a hierarchy with three types A, B and
C.  A is a child of B and B is a child of C:

  C
  +-- B
      +-- A

If, for some reason, these were registered in the order C, A, B, things
would break if we did the ancestry-walking.  C gets registered first and
immediately.  Then A gets registered, and the bindings would try to find
a known ancestor by walking up the hierarchy.  At this point, B is not
known, so C is chosen and A is set up to inherit from C.  It's only
after this that B gets registered.  A is never set up to inherit from B.

The only possibility to solve this issue in an automagical way seems to
be to do what pygtk does: Register types lazily as they are encountered
and use prefix guessing and name mangling to find out how to map
g_type_name to class names.  This guessing and mangling can't be done in
a reliable and extensible way.  So we[1] decided to use the manual
approach.

[1] Well, the other guys, I wasn't actually around at that time.

> about dealing with the breakage you outlined. from the last ~2 months worth
> of discussion on this topic, it should be clear by now that not everyone can
> be pleased with or without the current changes and variations thereof.

In addition to that, I'd link to bring up the issue of the why again.
As far as I understand it, the original motivation for making GObject
"floatable" is to have this functionality in GLib once and for all -- to
keep people from having to reinvent the wheel over and over again just
to get "sink" functionality.

The point that I think you haven't really addressed yet, and that muppet
already brought up, is why GtkObject's ancestry absolutely positively
needs to be changed in the middle of an API stable series (2.x).  Why
would it not suffice to add the floating stuff to GLib in some way but
keep the implementation in GtkObject untouched for now?  You had to
introduce quite a few ugly compatibility hacks to support different
version combinations; the Perl bindings and possibly other things break
-- does the desire to get rid of some code duplication really justify
this?

-- 
Bye,
-Torsten