Re: rework of the Gtk2-Perl type system

["muppet" <scott asofyet org>]

i made a prototype implementation of this stuff this weekend, following the
"take only what you neeeeeeeed to survive" principle (extra points to those
who catch the movie reference).

basically, i rewrote the core build_class method to use a GSList of ClassLevel
structs instead of a fixed array, and created gtk2_perl_add_class_mapping_rule
to specify a prefix and translation, e.g., replace the prefix "Foo" with
"Foo::" (based on what GC had already written); this was sufficient for my
test scenario, which only had one level and seven classes.

with this minimal change i can instantiate my extension's custom objects and
take them in and out of perl and they work perfectly with Gtk2 objects,
provided the packages' @ISAs are set up correctly.

i'm ready to commit this much if someone wants to play with it.


Christian Borup said:
> > The "require"
> > parameter lets you specify whether the class has a pm that must be loaded.

actually, once i got something implemented this weekend, i discovered that the
requires and uses do not kill the whole program if the pm cannot be found, so
the require flag isn't strictly necessary; it might be a good idea for
performance or correctness.



> > [discussion of renaming symbols]
>
> Your proposal seems sound to me.
> Could get_class and get_class_from_classname not be kept as defines, to let
> the existing code live on?

frankly, i don't think it's necessary.  grep reports 15 occurences of the two
symbols (get_class and get_class_from_classname) in the entirety of the
gtk2-perl source (before building, of course), and none in gnome2-perl.

gtk2-perl is still a young project --- y'gotta to nip those bad habits in the
bud!


> > Also, we could let the GType system do a lot of work for us by
> > implementing @ISA as a tied variable which uses
> > gtk2_perl_get_package_from_class, g_type_parent, and
> > g_type_get_class_from_package.
>
> Sounds cool.

i thought so.

> How would it perform?

no idea.  i hope that the lookup would only need to be done once, and the
result cached.  then again, if it's only done once it may be a lot of work for
no reward beyond just hand-coding (or autogenerating) a bunch of @<class>::ISA
assignments.

> And would it mess up the optimisations of method lookups? I assume not as
> the mappings should be pretty much stable.

after i wrote the initial message the other day i wound up rereading a lot of
the internals docs, and saw the bits about @ISA caching.  i think a tied var
would rather soundly break that. then again, a tied base which creates package
vars would probably not be so bad.

> Not sure how it would work though (which @ISA should be tied), have you got
> any examples of modules doing this?

er, not really.  was mostly just brainstorming with the thought of tie()ing. 
the old gtk-perl uses a "lazy loading" trick; the main Gtk.pm contains a long
list of @<package>::ISA = 'Gtk::_LazyLoader' lines; then the _LazyLoader
AUTOLOAD looks up the real parent class, boots that parent, and sets up an
@ISA to be cached.


so long as the project is using Inline, there will be a module for every
class, and most of them do a "use base ..." so their @ISAs are mostly correct.
 if/when we move away from Inline, this will be more important.


on the other hand, in testing this stuff with my pure XS extension, i
discovered that the parents aren't necessarily loaded at the right times.  i
made a change to Gtk2::_Object::AUTOLOAD which, in the case that the class on
which we are AUTOLOADing is actually a blessed object, attempts to load the
parent and try the method call again before die()ing with the "missing
function" warning.  this seems to work pretty well.



> Sorry for the late reply.

thanks for your thoughts!

-- 
muppet <scott asofyet org>