Re: rework of the Gtk2-Perl type system

[Guillaume Cottenceau <gc mandrakesoft com>]

"muppet" <scott asofyet org> writes:

> 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).

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

Well actually I think we can't do that: the (old) API call
"get_class" takes a GObject* as parameter, hence at that time I
don't see how you can "guess" if this pointer is actually a boxed
type. The information is not available. Am I missing something?
 

[...]

> > 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.

Ok. Looks nice. "Obliges" submodules to call a gtk2-perl
Depends.pm or like call, but hey how could we guess any another
way? Looks like a good solution.


[...]

> > 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.

Doing that from Depends.pm or like should be easy, I guess.
 

-- 
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/