Re: g_object_ref_sink and GUnowned

[Matthias Clasen <matthias clasen gmail com>]

On 1/3/06, Torsten Schoenfeld <kaffeetisch gmx de> wrote:
> 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?
>


Not commenting on the absolute necessity of changing the hierarchy,
but do you think it will be possible to do a release of the perl bindings
that works with both the old and the new hierarchy ? I'm asking because
I want to do a stable gtk release soon, and I don't want it to break the
perl bindings without at least a fix release in sight...

Matthias