Re: Patches that will come...

On Thu, Sep 02, 2004 at 02:06:21PM +0200, [email protected] wrote:

> > This is roughly what I was thinking. Except that the flags may well want
> > faking (or indirecting) so that there is no tail for the simple types (IV, NV,
> > RV and possibly pure PV). Likewise use the pmc cache slots for the NV and IV
> > data. That way at least some of the simple types don't need anything hanging
> > off.
> 
>   Eliminatig flags will break code like SvFLAGS(sv) |= ... but I agree
> with the general plan. It might be a good idea just killing SvFLAGS().
> and having SvFLAGS_get/set.

Did I say that I was going to break existing code? :-)

No. It's more evil than that.

SvNOKp() and SvNOK() and related NV flags calls are now functions that
call into the PMC. It doesn't actually matter what the storage is that
holds the flags, so a simple perl5 NV PMC can report true or false for these,
and hardwired false for all the other flags, such as IV and string flags.
This is done by the functions via the vtable, and when the PMC is upgraded
to a more complex type, the flags can be stored in an alternative way.

SvFLAGS() is also a function call. Anything requesting the SV's flags as
a 32 bit writable word is calling a function, which is able to upgrade any
of the simple types to something that does have space to hold all the
flags, and can populate them appropriately.

So I believe that it's possible to make it all work.

Nicholas Clark