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 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.
** My version of plain is weighted towards CS jargon. Anybody want to
take a swing at something *really* plain?
> 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.
> 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.
- Ken
