On Fri, 18 Aug 2000, Simon Cozens <[EMAIL PROTECTED]> wrote:
> RFC 131
{snipped}
Having pondered this (unsuccesfully) for a couple weeks, I will
certainly concede that this is the simplest way of handling this
problem.
A couple counter-points.
1. I believe your extrapolation from 'one strin
Simon Cozens writes:
: On Fri, Aug 18, 2000 at 09:57:59AM -0700, Larry Wall wrote:
: > Because we don't lose much efficiency to polymorphism, since we need it
: > anyway to support generic scalars, and we gain some efficiency whenever
: > we procrastinate conversions out of existence.
:
: Surely
On Fri, Aug 18, 2000 at 09:57:59AM -0700, Larry Wall wrote:
> Because we don't lose much efficiency to polymorphism, since we need it
> anyway to support generic scalars, and we gain some efficiency whenever
> we procrastinate conversions out of existence.
Surely we do, because we have to add in
[EMAIL PROTECTED] writes:
: A single internal encoding which is opaque to the programmer Would Be Nice.
We seem to be asking for contradictory things here. If it's truly
opaque, the programmer shouldn't care whether it's polymorphic or
monomorphic. I'm inclined to think the polymorphic solution
On Fri, Aug 18, 2000 at 10:22:13AM -0500, Jarkko Hietaniemi wrote:
> Danger! Only the implementer(s) of this pluggable data storage and
> its interface should care about details like "an array of wchars".
> All other people, even other core people, should use just the
> interface, not do things l
> That's the thing. It doesn't matter. It B matter. Keep it
> pluggable; you could have everything in Latin1, in UTF8, in UTF16, or
> who knows what, but the core developer shouldn't have to care. One good
> way to achieve this is to have the string presented in the variable as
> an array of wchar
> Internal String Storage to be Opaque
> Number: 131
> =item Why a single internal encoding?
FWIW, I would like to throw my support behind this proposal.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
