Re: rework of the Gtk2-Perl type system

"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 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 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 or like should be easy, I guess.

Guillaume Cottenceau -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]