develooper Front page | perl.perl5.porters | Postings from February 2001

Re: The State of The Unicode

Thread Previous | Thread Next
Jarkko Hietaniemi
February 19, 2001 17:02
Re: The State of The Unicode
Message ID:
> The design is simple to understand, it's intuitive, it's what's in the Camel
> and IT WORKS.

Rereading the messages of the thread I am becoming more and more confused.

Of course I'm hopelessly biased on the matter, so take the following
with a biiig grain of salt, but to me it seems like the 'naysayers' of
the current implementation are the ones getting hung on the bytes vs
characters issues, they are the ones worrying about internal
representation.  If all the handling that is supposed to be
"transparent" -- _and_it_currently_is_ -- what is the problem?

I drafted the big \xHH vs \x{HH} vs chr vs v vs .. table, and
(I thought) all I talked about was the internal representation, how
many bytes are generated where.  There were *internal* inconsistencies
and I straightened them out.  I do agree that _for_the_normal_user_
whether chr(128) is internally one or two bytes long shouldn't matter:
and guess what, currently chr(128) eq "\x80" && chr(128) eq "\x{80}"
&& chr(128) eq v128 && chr(128) eq pack("C", 128).  So what's the
problem we are trying to solve here?

$jhi++; #
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About