At 07:11 PM 2/5/2001 +0100, Edwin Steiner wrote:
>Branden wrote:
>[...]
> > Edwin Steiner wrote:
>[...]
> > > I wonder how many data types will directly rely on vtable layout. I would
> > > think all data types implemented outside the core will use an additional
> > > level of indirection (tie-like callbacks?). So maybe there will only be
> > > a hand full of 'very internal' data types depending on the vtables.
> >
> > I actually don't see the need for having a `tie'-like interface. To me, at
> > least, vtables are much more clear to deal with than a `tie'-like
> interface.
> > Of course, we don't want to PMC->vtable[ADD][UTF_32](DEST, PMC1, PMC2);
> > ourselves, but we could actually have a SV_ADD_UTF32(DEST, PMC1, PMC2)
> macro
> > that would expand to that, and so on. Here the macros really buy us
> > something... Having them implemented directly over the vtables, we won't
> > have version-portability problems, and won't have to write that ugly piece
> > of code either.
There may be macros used by the opcode functions, but that's it. I'm not
sure it's worth it to define a zillion macros that'll be used once or
twice. (Or even at all--the vtable layout leaves some interesting generic
possibilities for translating lots of bytecodes to one or two opcodes)
>I thought of the `tie'-like thing because of Dan's:
>
>" 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. "
>
>I don't really have a qualified opinion about it myself.
Tie will probably override the vtables, though I expect in general most of
the functions that a tied variable will implement will be provided by perl.
(You may, for example, write a general FETCH and STORE function while perl
handles converting the results to the appropriate data type, and fills in
its own add function, along with all the others)
One of the reasons to *not* use the vtable API for tie is that the vtable
API may well go away. It might turn out that it's less of a performance win
(or a perfomance loss) than we'd hoped, or that it's just too damn
complicated to be worth the benefits.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
