At 10:13 AM 8/6/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > >IMHO it would be a lot easier to read the
> > >code if we clearly differentiated between what's now called SV and the
> > >collection of xpv*'s.
> >
> > I agree. That's why I yanked in the PMC designation. :-)
>
>PMC isn't any easier than SV.
I chose PMC for external (including most extensions) use on purpose. I
specifically wanted it to be clear that the code was handing an opaque
token, one that it should make absolutely no assumptions about.
>I think we should call it a binding. Bindings hold values. Environments
>are just collections of bindings. A closure is an environment attached to
>code. If we can adopt plain ** english naming conventions and document
>them in a glossary pod I think reading the code will be a lot easier.
That's not a bad idea, but it's too long as an implementation name. I
really am proposing something like:
typedef PMC struct sv *;
We can call 'em bindings in the docs, but that's too much to type.
> > If a scalar changes implementation, they change the
> > vtable for it. So, for example, when the integer array code is required to
> > promote an element to a full scalar, it promotes the whole array then
> > changes the vtable pointer to point to the scalar array vtable.
>
>But that's a local decision to be made by the implementation of the
>integer array object. It might choose to swap in an overlay instead. This
>is the reason vtables are so nice.
Right, I know. I've seen the joys of vtables. I'm waiting to see the
downside, but that's for later.
> > Flags are still needed, since there will be some generic state--is the
> > pointer valid, can it be moved, is the representation fixed or changeable,
> > stuff like that. The number of flags may well be very limited, with most of
> > the flag functionality subsumed by vtable code, and that's OK by me.
>
>Cool. If a vtable implementation needs extra flags, it can provide them
>itself then, i.e. we don't have to worry about sizing the flags attribute
>to hold all the flags that all types would ever need.
There really are three classes of flags.
1) Static flags related to the variable type. This can be hardcoded in the
flags routine of the vtable.
2) Dynamic flags specific to a particular variable. These can hang off the
sv_any pointer in the variable-specific data area
3) Globalish flags common to all variables
If we don't come up with any of type #3, and we might not, I'm all for
tossing the flags field.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
