On 1/3/06, Torsten Schoenfeld <[EMAIL PROTECTED]> 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
_______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
