Re: g_object_ref_sink and GUnowned

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

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
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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]