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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list