Re: g_object_ref_sink and GUnowned

[Tim Janik <timj imendio com>]

On Sat, 31 Dec 2005, Torsten Schoenfeld wrote:

> On Thu, 2005-12-22 at 17:49 +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?

> type and, if it is known to the bindings, put the associated namespace
> into Perl's inheritance mechanism.
>
> GInitiallyUnowned is not known to our GLib bindings, though, which
> results in Gtk2::Object having no ancestor.  That in turn means that
> things like windows, containers, etc. are no Glib::Object -- they don't
> have access to, say, the signal and property API anymore.  This breaks
> every non-trivial Gtk2-Perl program.  Even if we added support for
> GInitiallyUnowned now, older versions of our bindings would still break
> if the underlying GLib is updated without also updating the bindings.
>
> 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.

>  However, the current approach works
> with all combinations of GLib 2.[02468] and GTK+ 2.[02468].  The only
> thing it assumes is that the object hierarchy doesn't suddenly contain
> unknown types, which is, I think, a sensible assumption.

i don't agree here, like i just said. we do not take away parent types
from a derived type, because that'd incompatibly reduce the set of
operations you can apply to that type, and we maintain binary
compatibility in terms of structure and prototype layout.
but that does not exclude addition of new dynamic (parent) types, and
i don't think i'd be happy with committing to such a limitation for
the future.

> For reference, the code that implements the described approach is in
> gperl_register_object:
>
> http://cvs.sourceforge.net/viewcvs.py/gtk2-perl/gtk2-perl-xs/Glib/GObject.xs?rev=1.53&view=markup
>
> The GTK+ bindings use
>
>  gperl_register_object (GTK_TYPE_OBJECT, "Gtk2::Object")
>
> to register the type.

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.
at this point, i'm inclined to leave things as they are in CVS (which already
goes through quite some length to ensure compatibility) and just wait for
people and software to adapt to it (which so far seem to be only the perl
bindings).
we can put a prominent notice in the glib-2.10 release notes about this glib
version breaking with assumptions that older perl bindings make, and that
upgrades of the perl bindings together with glib are required to keep the
gtk perl bindings working.

> --
> Bye,
> -Torsten

---
ciaoTJ