Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
>
>This is similar to the structure used in perl 5, with one major
>difference. Rather than having all the intellegence needed to use a
>variable separate from that variable, this RFC embeds that information
>into the variable itself. This allows for more efficient code to
>access the vriables, and it lets us add in variable types on the
>fly. 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.
>
>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.
>
>Implementation on various types (arrays, hashes, scalars) as well as
>sub-types (integer scalars, string scalars, objects) is left to
>another RFC.
All good so far.
>
>=head1 IMPLEMENTATION
>
>The base variable structure looks like:
>
> struct {
> IV GC_data;
> void *variable_data;
> IV flags;
> void *vtable;
> void *sync_data;
> }
>
>The fields, in order, are:
>
>=over 4
>
>
>=item variable_data
>
>Equivalent to perl5's sv_any pointer, this is a pointer to the actual
>data structure for the variable. It may, in certain cases, be coopted
>to hold the actual value. (This is likely the case for a scalar that
>holds just an integer, where the native int size is equal to or
>smaller than the native pointer size)
I think we should allow more than just a pointer, and that really
simple variables (IV, NV) should be able to use _just_
the structure above without auxillary malloc'ed data.
>
>The actual structure that hangs off will depend both on the class of
>variable (scalar, hash, array) and the type of that class (integer
>array, integer scalar, filehandle, reference) and isn't specified here
>
>=item flags
>
>This field holds various flags that hold the status of the
>variable. (Flags to be RFC'd later)
>
>=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)
>
>vtable contents will be RFCd separately. All variables will share a
>common set of functions, though scalars, arrays, and hashes will have
>their own set of extensions on top of that.
The vtable should be non-opaque to the perl-core.
>
>=head1 IMPACT ON EMBEDDING
>
>None. Generally embedding apps won't deal with actual perl data
>
>=head1 IMPACT ON EXTENSIONS
>
>None. Extensions get pointers to this structure, which as far as they
>know is a magic cookie. (In fact the official perl term for the thing
>handed to extensions is a Perl Magic Cookie, or PMC) Knowledge of the
>internals is a no-no at this level.
Moot - I think there are two classes of "extension":
A. As above that treat this stuff as opaque.
B. External "ops" - which will assume same as ops below - i.e.
they can call via vtable etc.
>
>=head1 IMPACT ON OP FUNCTIONS
>
>Op functions have intimate knowledge of the internals and unrestricted
>access. Therefore they're assumed to know what they're doing, and will
>therefore heed the info in this RFC.
>
>=head1 REFERENCES
>
>sv.h
--
Nick Ing-Simmons
