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";
}