David Mitchell <[EMAIL PROTECTED]> writes:
>> > 2. Each SV has 2 vtable pointers - one for it's numeric representation
>> > (if any), and one for its string represenation (if any). Flexible, but
>> > may require an extra 4/8 bytes per SV.
>>
>> It may not be terrible. How big is the average SV already anyway?
>
>True, but I've just realised a complication with my suggestion. If
>there are a multiple vtable ptrs per SV, which type 'owns' the SV carcass,
Perl owns the carcass. Each vtable would have its own payload portion
and be responsible for its destruction and cleanup.
This is classical "multiple inheritance" scheme.
>and is responsible for destruction, and has permission to put its
>own stuff in the payload area etc? I think madness might this way lie.
>
>So here's a modified suggestion. Rather than having 2 vtable ptrs per scalar,
>we allow a string type to contain an optional pointer to another
>subsidiary SV containing its numeric value. (And vice versa).
That would work too.
>
>Then for example the getint() method for a utf8 string type might look like:
>
>utf8_getint(SV *sv) {
> if (sv->subsidiary_numeric_sv == NULL) {
> sv->subsidiary_numeric_sv = Numeric->new(aton(sv->value));
> }
> return sv->subsidiary_numeric_sv->getint();
>}
>
>(uft8 stringgy methods that alter the string value of the SV are then
>responsible for either destroying the subsidiary numeric SV, or for making
>sure it's value gets updated, or for setting a flag warning that it's
>value needs recalculating.)
>
>Similarly, the stringy methods for numeric types are wrappers that
>optionally create a subsidiary string SV, then pass the call onto that
>object.
>
>Or to avoid the conditional each time, there could be 2 vtables for each
>type, containing 'with subsidiary' and 'without subsidiary' methods;
>the role of the latter being to create the subsidiary SV and update the
>type of the main SV to the 'with subsidiary' type.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
