Re: rework of the Gtk2-Perl type system

["muppet" <scott asofyet org>]

Guillaume Cottenceau said:
> There's also another problem, but I don't think it can be
> addressed (or at least I don't know how), due to the way C works:
> when you use get_class with a boxed type (or anything else,
> actually) instead of a GObject, you segfault trying to
> dereference fields of the supposed GObject structure. This is
> unsafe. But this is C :/.

hrm...  looks like it barfs when it tries to consider the first element of a
GTypeInstance to be a pointer to a GTypeClass.

normally you'd avoid this by having the first byte or two of the base struct
be a constant set of id bytes, so you can sanity check to see if this section
of memory is actually what you think it is, but it looks like they didn't do
that (probably to save those wasted bytes).

so, we'd need a way to specify that the boxed types are not objects.

itemized enumeration to the rescue!  when registering a class_mapping, you
could specify a boolean which tells whether the class is a GObject subclass.



> Not to say that the mapping rules are a bit hackish, especially
> for GLib stuff.

hehe, getting around sticky issues like that is why the one-to-one mappings
look so nice; they completely sidestep the issues altogether.



> > Basically, if you don't have a *.pm for the class you've mapped, the
> > script will die in the require_pv call because perl can't find the
> > required file.
>
> Well, according to perlapi(1), it's not entirely true. The api
> call I've chosen seems to be eval'ed (can't remember if I did it
> on purpose or not).

i figured that out after writing my original message.  turns out to be a lucky
accident.




> > ExtUtils::Depends, called from Makefile.PL.  (In fact, ExtUtils::Depends
> > also installs typemaps and headers and config information needed for
> > building client modules.  It's very cool, and i think we should use it.)
>
> I confess I'll have to read more of gtk-perl sourcecode: I have
> no idea what you're talking about :/.

check out Depends.pm in the top level of the GtkPerl archive.  if you have
GtkPerl installed, it's probably already on your system.  (GtkPerl comes
installed by default on mandrake, IIRC.)

you can chain modules by dependency.  for example, in GtkHTML, Makefile.PL
creates a Depends object based on Gtk, which pulls in all of the configuration
options, namely typemaps, headers, CFLAGS and LDFLAGS needed to compile
against the Gtk module and any of its dependencies.  by calling save_config on
the Depends object, you set it up to save this new module's dependency
information so somebody else can chain off of you.  quite nice.  i was
thinking of writing something similiar, but that does everything already.


> > On the other hand, it might also be possible to do something like
> >
> >    void gtk2_perl_register_class_mapping_rule (char * perl_code_to_eval)
> >
> > which would allow you somehow to specify a substitution pattern for a
> > whole set of mappings, to be run as a code reference, and successful
> > results cached to avoid running it again.  I am willing to implement this,
> > but i want help designing that portion of the interface.
>
> I tend to prefer the first form: it seems more readable and less
> error-prone to me. [...] It seems to me that first way of
> registration, with an enumeration of all mappings, would be safe
> to my eyes.

that was my thinking, too.  explicit and verbose is good sometimes.

alright...  my next rev will move to the one-to-one mappings.




> > 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.
>
> I don't understand. Maybe if you gave an example, it would help
> me to see what you're talking about? Excuse my slow brain..

i think i mostly talked myself out of this in reply to ./borup earlier.


-- 
muppet <scott asofyet org>