> > It seems to me the following options are poossible:
> >
> > 1. We no longer save conversions, so
> > $i="3"; $j+=$i for (...);
> > does an aton() or similar each time round the loop
>
> I fear this would be a performance hit. I'm told TCL pre version 8 was
> like this - everything's a string and converted to a number each and every
> time the number is needed.
Yes, I fear the same!
>
> > 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,
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).
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.
