Front page | perl.perl5.porters |
Postings from September 2000
(sorry if theis reply is late, but perlmail.valueclick.com blocked my mail
for some time)
On Thu, Sep 14, 2000 at 09:48:57AM +0100, "Moore, Paul" <Paul.Moore@uk.origin-it.com> wrote:
> >From my (uninformed) reading of the various Unicode discussions, it seems to
> me that there is a confusion over what a "Perl string" is supposed to be. To
> the best of my knowledge, the intention is that a string in Perl is simply a
> sequence of characters, where ord() of each character is *not* limited to
> 0..255. The internal representation is irrelevant, except to low-level
> "guts" type code.
This is a very wrong way to view this, as it throws perl direcly into the
same problem as tcl, nameyl the inability to handle binary data.
Being able to handle binary data transparently is a *must* for perl. As
soon as perl starts to convert my jpeg images or audio data into utf-8 I
will probably have to switch to a real computer language.
> guts" comment above, and is simply that the internal representation exposes
> itself at too high a level to be entirely comfortable - specifically, at the
> XS level, where most C functions do *not* expect UTF-8, so that XS interface
No. Pelr *must* support binary data *and* strings. At the moment, this
happens to be byte strings and utf8-strings, but this does not need to stay
that way.
Throwing away the ability to transparently handle binary data (even if it
can be extracted later on) is not a viable solution.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Thread Previous
|
Thread Next