Garrett Goebel wrote:
> I thought one of the benefits of vtables was to facilitate extending
support
> for new types?
>
> Does RFC 32 have any place in this discussion?
Yes!!!
> Per RFC 32: A method of allowing foreign objects in perl
> >
> > Since writing half a zillion perl2WhoKnowsWhat modules is
> > going to be unweildy, not to mention different for each and
> > every object type, perl punts. We require that the code we
> > interface to defines a dispatch function for each object,
> > and we then just call the dispatch function with enough
> > information for it to Do The Right Thing.
> >
> > From the perl programmer's point of view, foreign objects
> > and native objects look the same. Perl will define some
> > generic conversion routines (to int, float, and string)
> > which the foreign code is welcome to override if it wishes.
I guess `object' would have a vtable of its own, having entries for
CALL_METHOD and DESTROY (among others). DESTROY should be responsible for
call the external object's destructor, when perl's GC sees that the object
can be freed. CALL_METHOD would get called every time that $xyz->abcde gets
called. The vtable of scalars should have, besides the DEREF_ARRAY and
DEREF_HASH entries, one DEREF_OBJECT entry, to return a value with the
vtable containing CALL_METHOD and DESTROY entries. With this, it would be
possible to build a `generic' framework to extend Perl with objects of C++,
another `generic' framework for Scheme, etc. for qw(Java Python Ruby ...),
or even non-OO languages as C (what did you expect?).
I _think_ ``RFC 92: Extensible Meta-Object Protocol'' goes in here too,
since CALL_METHOD could be overridden to implement another method lookup
algorythm.
Note that a blessed hash would have both DEREF_HASH and DEREF_OBJECT entries
of it's scalar reference working, so that it's possible to do $x->{foo} and
$x->bar (the former would call DEREF_HASH and then FETCH from the hash
vtable, and the latter would call DEREF_OBJECT from $x and then CALL_METHOD
with `bar' and an empty list [the arguments] as parameters.)
- Branden
