At 12:07 PM 8/5/00 +0000, Nick Ing-Simmons wrote:
>Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
> >=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.
Fair enough. I was thinking of keeping this structure as small as possible,
but it's really not SVs that eat up all the space, it's arrays and hashes.
Optimizing those (like with the string/integer/number arrays Chip was
talking about) would buy us a lot more than shaving off a few bytes here, I
expect.
We'll have to be careful to size this appropriately, but that's just
another job for Configure. :)
> >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.
Yes. The core will know that the first function returns the variable type,
the second the type name, the third the integer value, and so on.
> >=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.
Three classes, which is why the three lines here. I'm picturing a very
simple, probably not too fast, high-level interface for embedding apps, a
reasonably fast, middle level for extensions that's still protected from
change, and a low-level, fast interface for op type stuff that has intimate
knowledge of the guts.
I've an RFC on this (I'm starting to sound like Damian--If I start talking
with an Australian accent, would someone smack me please? :) which I'll get
out RSN.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
