Dan Sugalski wrote:
> The vtable stuff won't be exposed outside the core. This means embedding
> programs and extensions will *not* be using it. Generally speaking, it'll
> be opcode functions only that'll be hitting the vtables.
What? I thought it would replace most of sv_... functions (that of course
could be macros doing the PMC->vtable[STORE](DEST, PMC1, PMC2) stuff), and I
thought the magic messy interface of Perl5 would disappear, since it can be
fully supplied by vtables (am I right?). So, extensions that deal with what
used to be tied variables (and overloading, that now could be done with this
too -- am I right again?) should know the details of vtables and use them to
implement magic.
> While I'm not hugely averse to some macro-ization, I don't think this is a
> spot worth that much mental effort, at least not for individual vtable
> calls, which will probably be looking like:
>
> PMC->vtable[ADD][UTF_32](DEST, PMC1, PMC2);
>
> Also, as a sort of side thing, don't expect the vtables for each type to
be
> all that different, if at all. Conceptually I'm not sure it's worth trying
> to segregate them out to scalar, hash, array, and list vtable types. (Plus
> we get a minor benefit in that if they all have an identical set of vtable
> slots things won't go bang really badly if an incorrect PMC slps in
somewhere)
I think that's bad. This is actually one of the things that bother me most
in XS. In Perl code, there's _NO_ way an incorrect PMC slps in the wrong
place. The only way that I could store scalar/list objects in the same place
is references, and if I try to dereference with $$_ a reference to an array,
I get in trouble. In XS, as everything is castable to SV*, I could actually
set a scalar as $_ with an AV*, and that's bad, IMO. And about references, I
think it's a good thing a variable having _both_ array and hash references,
so I proposed the separate DEREF_ARRAY and DEREF_HASH entries, so that %$_
and @$_ can actually be different representations of the same thing (useful
for database rows...)
I also don't see how it wouldn't bang badly if we get an incorrect PMC. How
would we extract the 5th element of a scalar? And how would we read one line
out of an array? Sum two hashes? I think having only one vtable for all
would only put a burden on who implements a vtable to croak an error on not
supported types.
- Branden
