At 4:57 PM +0200 10/19/02, Leopold Toetsch wrote:

struct {
    can;
    has;
    isa;
    union {
      scalar_vtable;
      aggregate_vtable;
      object_vtable;
    };
VTABLE;

Rather than a union, there'd be a set of pointers to various vtable pieces.

But a scalar (PerlInt) doesn't have all the _keyed methods. An aggregate doesn't need all the arithmetic or binary vtable entries. So IMHO the union would be a way to have smaller vtable pieces.
Well... the problem is with references. Larry's declared that a reference must act identically to its referent if used in the right context. We could force an explicit deref, but I'd rather not. Treating the reference as if it were the array or hash itself makes things fit better conceptually, at least for me.

What I'd like to be able to do is, for variables that are effectively passive and don't actually have to get involved, to skip that extra level of indirection and promote the value's vtable functions into the variable's vtable.

So we would have e.g.:

- Plain scalar:
  vtable->var.get_integer => return cache.int_val
        ->val.get_integer => return cache.int_val
Yep.

- Tied scalar:
  vtable->var.get_integer => call tie magic (updating the value) =>
        ->val.get_integer => return cache.int_val
Close. (Or the same if I'm misreading) Like:

-tied
vtable->var.get_integer => call tie magic to get value PMC
->tie_magic_returned_pmc.get_integer => reurn cache.int_val

(Assuming in both cases that the int value is cached and doesn't need to be string converted or anything)
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk

Reply via email to