2000-09-26-21:11:53 Paris Sinclair:
> Please keep your fetishes and/or geocentricism to yourself.
They get all ingrown and infested if I don't take 'em out and
air 'em out occasionally:-).
> There is no need to propose that others should share them.
No indeedy! I'm not opposed to i18n support in perl, or anywhere
else. In much the same way that I'm not opposed to various other
anti-discrimination measures even though I'm not in any of the
discriminated-against populations they aim to aid.
> If Perl is going to exist into the future, if Perl is going to be
> a great programming language for Humans, then it needs to support
> the different ways that Humans communicate.
That sounds positively noble when you put it that way. I can
actually hear choirs of cherubim providing atmosphere.
> Extending the context of C<tr///> is an excellent general
> sollution to many problems, in many languages.
That's an interesting claim, and for all I know it could be true. If
folks believe it, and think it's a justification for the proposed
behavior in tr///, let's get this claim made nice and explicit in
the RFC, is all I'm saying.
> And yes, a list of 250 items to store 5 items is HUGE. There is no way to
> know how many items I will have.
Yup, but as long as you're working with 8-bit encodings the array
will never get bigger than 256.
> O(N*50) is never going to make me happy.
O(1) should make you happy. It's got a small fixed upper bound.
Unless, of course, split// and ord get interesting in the face of
UTF-32 or something and the data is no longer bounded, in which case
(as I said) your only hope is to change the [] to {}, at which point
it's probably as fast as the hyper-sexy hash-building-tr///.
> Which is why right now I would have to use a funky C<map>
> and C<eval>.
You've lost me. If you want a hash, what's wrong with:
$hist{$_}++ for split //, $string;
What's all this about eval?
-Bennett
PGP signature
