[EMAIL PROTECTED] writes:
: This way perl doesn't, for example, have to know how to access an
: individual element of an array of integers--it just asks the array to
: return it a particular element. Code MUST use the vtable functions to
: get or set values from variables. They MUST NOT directly access the data.
Fine, though we'll have to decide how indexes and keys get passed in to
these functions (vfuncs?). We could pass such parameters on the stack
or as function arguments. At a guess, we'll end up providing both
APIs. Which API will be more basic is anyone's guess. 'Course, this
is outside the scope of this RFC anyway.
: This base structure should be considered immobile, so it's safe to
: maintain pointers to it. The data portion of a variable should be
: considered moveable, and may be shuffled around if a variable changes
: its type, or the garbage collector needs to compact the heap.
If it's only compacting the heap, I don't know whether I'd call it "the
garbage collector". Catching cycles has to involve the PMCs too.
: =item GC_data
:
: Random data for the garbage collector, whichever one is used. This
: could be a marker for M&S GC, or a refcount for refcount GC, or just
: nothing at all if we get a really clever GC.
We'll need to decide if we're really going to make people release their
PMC pointers explicitly. This is required for refcount GC, and can
help some forms of "real" GC do their work more efficient, but slows
down other forms of GC.
: =item vtable
:
: The vtable field holds a pointer to the vtable for a variable. Each
: variable type has its own vtable, holding pointers to functions for
: the variable. Vtables are shared between variables of the same
: type. (All integer arrays have the same vtable, as do all string
: scalars and so on)
I think that last statement is false. I think strings will have
several vtables depending on their format. (So might integers, if we
decide to stitch in bigints.)
Larry
