We've been kind of sloppy with variables and values so far--not too
surprising as perl 5 was, and many languages (like C) don't make much
of a distinction, and the distinction doesn't much matter even where
it does exist.
We can't do that any more, unfortunately. That's something of a pity,
as it makes things easier, which should've been a clue that we don't
get to do it that way. :)
A "thing" has three parts, a name (which is optional), a container,
and the contents of the container.
The name lives in a symbol table or scratchpad somewhere, and has a
pointer to the container. That's *all* it has, and is otherwise of no
particular use.
The container part is the variable. It holds the value, and is what
mediates assignment. You must go through the variable when storing the
value, and you must go through the variable when fetching the
value. Unfortunately this also means, in the general case, when doing
any access at all of the value in the variable. Luckily in the normal
case we can skip this indirection. Variables also have properties.
The thing in the container is the value. It also has a type, a vtable
that mediates activities involving the value, and properties. Which
are separate from the variable properties. (Which, again, are
separate from attributes)
What does this mean for us?
Well, first it means we need to conceptually split "variables" into
three parts, rather than two as we have been.
It also means that we need to (or at least really should) split
vtables up into parts, so we can pull them upwards as
appropriate. That way we can promote vtable pieces where appropriate,
when the value and variable are of the same type, to cut out dispatch
overhead. And in those cases where we can't do that, we can do the
normal two-level access. (Though hopefully we can avoid it for most
anything besides objects and aggregates)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
