Domovoy <domovoy errlock org> writes:
Glib::Type->register_object
That's the fundamental part. Glib::Object::Subclass is only a front end to it. You can register_object() yourself if desired.
our %signals = ( our %properties = (
That info just disappears into glib normally, no need to retain it at the perl level unless it made the setups look much better.
'Variable "@ISA" is not imported' (??).
Full mangling I tried below, in case it helps.
'use parent Exporter;'
That pushes on the end of @ISA if I'm not mistaken, so order may still be important.
package Glib::Object::Base; *new = \&Glib::Object::new; package Glib::Object::Subclass; unshift @{ $class."::ISA" }, qw/Glib::Object::Base/;
Yes, something like that, with whatever name for the little extra class. Maybe Glib::Object::New if a new() is it's only purpose. Perhaps in it's own .pm file too, as a multi-inheritance mix-in for similar use elsewhere too.
Now, the only thing that actually really happens in that 'import' sub is the call to Glib::Type->register_object. Does it have to be called _before_ the class definition, or can we do that in the 'new' sub?
Presumably that would work, but it would mean the hierarchy wouldn't be established on loading, so a class method Foo::Bar->isa('Glib::Object') wouldn't be true until the first new(). Probably undesirable usually, but not actively harmful.
So if Exporter should be avoided in oop, so is import, and Glib::Object::Subclass is still doing something wrong.
I expect an import() in the class itself wouldn't suffer the same @ISA order trouble. But perhaps nobody has ever done that either :-).
Attachment:
Foo.pm
Description: Text Data
use strict; use warnings; use Gtk2 '-init'; use lib '.'; use Foo; my $foo = Foo->new; print "$foo\n"; use Foo 'SOME_CONST'; print SOME_CONST(),"\n"; $,=''; foreach ('Glib::Object::Subclass', 'Gtk2::ScrolledWindow', 'Glib::Object::_Unregistered::AtkImplementorIface', 'Gtk2::Buildable') { print $_,' ',($_->can('import')//'undef'),"\n"; }