Please apply the attached patch to Glib 1.051, and test any and all of your code that creates custom GObject types in perl. Report *any* problems immediately; if possible, send or point me to the code that fails, with a description of what it is supposed to be doing.
Attachment:
Subclass.patch
Description: Binary data
One of the goals of the 1.05x series of Glib is to address issues with Glib::Object::Subclass, namely that its current implementation is not suitable if you need to be able to eval() code containing a Subclass. I have made changes that should address this issue in a completely backwards-compatible and largely transparent way, but we need testing from the user community to ensure that these changes will not break any existing apps.
By the way, as i am asking you to test a patch to an unstable release, *please* don't install as root to your system perl library! The README contains instructions for installing to a non-standard place, and you can use that to override the Glib you already have installed without disturbing it.
The Nitty-Gritty: -----------------(This is the part where i explain in gory detail what's going on for those who are interested. You can safely skip this, unless you want to help debug anything for me.)
The actual registration of a new Glib::Object type from perl is handled by Glib::Type::register_object(). Glib::Object::Subclass is a pragamatic-style module which calls Glib::Type::register_object() with the proper classname for you, and provides "reasonable default" implementations of GET_PROPERTY(), SET_PROPERTY(), and new() if your class doesn't already define them.
G::O::Subclass::import() is where all of this magic happens. Now, the problem is that 'use' happens during compilation, and import() will be run before the calling module has been completely parsed. This means that if you define a new() a few lines after the Subclass line, Subclass's import() can't see it. Therefore, Subclass defers the symbol check until as late as possible with a CHECK block (which gets executed after compilation, just before the run stage).
The number one problem here is that CHECK blocks cannot be run inside an eval(), simply because execution has already started. If you create a module that 'use's Subclass, and then eval() code that 'use's that module, you will see "Too late to run CHECK block" and your code will be missing the default new(), GET_*() & SET_*() functions. (I know that Gimp-Perl ran into this problem.) The workaround is to eschew Subclass altogether and call Glib::Type::register_object() directly.
So, my goal here is to remove the need for the CHECK block from Subclass. new() can be inherited by simply prepending Glib::Object::Subclass to the newly-registered class's @ISA (allowing for normal perl method overrides), but the property functions cannot.
Subclass's default property getter and setter also have other problems, which were addressed at length in http://lists.gnome.org/archives/gtk-perl-list/2004-June/msg00091.html and http://lists.gnome.org/archives/gtk-perl-list/2004-June/msg00170.html and finally released in Glib 1.051. This essentially renders obsolete the GET_PROPERTY and SET_PROPERTY installed by Subclass and they are not needed.
The main difference is that the semantics of the properties are slightly different in edge cases now -- you get default values now instead of undef when the property is unset, the property interface can provide storage by default (which is what Subclass previously added for you), and failovers are a little different -- but most of these things are issues that you'd have to resolve explicitly with the old code before it would even work properly. In all of my testcases, everything works out as expected, but real user testing is where you find the truly pathological cases, so i must come to you. :-)
-- elysse (in labor): is the head the biggest part? midwife: yes. elysse: oh, good.