On Wednesday, November 19, 2003, at 05:47 AM, Bjarne Steinsbø wrote:
GBoxed is DERIVABLE, but it's not DEEP_DERIVABLE, right?
yes. boxed types are not deep-derivable because they are allowed to be
opaque, which means the compiler doesn't know how big they are.
In "perl language" this should be equivalent to
@Any::Boxed::Type::ISA = ('Glib::Boxed');
a single inheritance, yes.
In GBoxed.xs, a boxed type is wrapped up in a BoxedInfo struct, so
that a boxed type (from perl's point of view) can know it's own
gtype/package_name.
and also so that the boxed object's perl wrapper knows whether it owns
the object to which it points. this is an important detail, and is why
the extra layer of indirection exists. HOWEVER, that extra layer is an
implementation detail and you shouldn't know about it outside of
GBoxed.xs. all you need to know is that the perl representation of a
boxed type is determined completely by its GPerlBoxedWrapperClass, and
only that wrapper class knows how to wrap and unwrap those objects.
I could have understood the need for a recursive lookup routine if
GBoxed was DEEP_DERIVABLE, especially in the presense of multiple
inheritance, but Glib doesn't allow multiple inheritance, and any
boxed type inherits directly from GBoxed. So why not just look it up
in the hash and leave it at that?
because Perl does not prevent you from re-blessing any scalar
reference. okay, that's not entirely true, as you can set the scalar
read-only, but that prevents some cool and important hacks, so long as
you ensure that the original type is in @ISA, we support this.
for example, Gtk2 handles the polymorphic nature of GdkEvent (which is
a union of event structures, discriminated by a type key) by
re-blessing the Gtk2::Gdk::Event into a subtype which has defined the
particular methods for getting to that event's members. this allows
syntax like
$event->button; # where $event is a Gtk2::Gdk::Event::Button
$event->keyval; # where $event is a Gtk2::Gdk::Event::Key
the alternative would've been very messy.
I guess the part I don't understand has something to do with the
interplay of @ISA and the Glib inheritance...
it does have a few idiosyncrasies. perl's model is very simple
(depth-first search through @ISA), but Glib's model has several rules;
no multiple inheritance, interfaces, uninstantiatable types that
*really* can't be instantiated, etc. we map as much as we can to
Perl's rules (support GInterfaces by adding them to @ISA, gtype to
package mappings), but we cannot stop people from using the Perl rules
that they know and love, so we also have to ensure that things won't
break in the hands of pathologically eclectic rubbish listers... like
us. :-)
--
"that's it! you're a genius!" "yes. that's what i think. do you
think i deserve a raise?"
- dialogue from 'Godzilla versus Mothra', 1964
|
