Gurusamy Sarathy <gsar(_at_)activestate(_dot_)com> writes:
I'm beginning to see where you are not "getting" it. You are
arguing from the POV of some mythical implementation that doesn't
exist.
Yes he is - in fact suggesting that such an implementation may be superior.
At this stage of unicode support - it makes sense to at least
consider such alternatives.
One way of looking at this might be to have an SvCHAROK flag akin to SvPOK
but _without_ a corresponding change in internal representation.
(Although such alternate representation may be useful for utf16 or to
provide a slot for the encoding.)
Data starts off neutral. When an op treats the string as 'chars'
(due to expicit utf8/locale in scope or whatever) the bit gets set.
Then later when data is processed by an op that can jump
either way it can use the flag to decide. A bit like SvIOK vs SvPOK behaves
with & etc.
--
Nick Ing-Simmons <nik(_at_)tiuk(_dot_)ti(_dot_)com>
Via, but not speaking for: Texas Instruments Ltd.
