If you feel that the functions here within might be useful for
your application, this possibly indicates a mismatch between
your mental model of Perl Unicode and the current reality.

As "how to stop Perl from messing up binary data I'm handling based on
the misconception that it MUST be text" is a problem I regularly have to
deal with, I think the "mental mismatch" is rather located on a bunch of
other minds ....

T (01-03-19, 04:34 AM)

On 12/27/18 1:15 PM, Rainer Weikusat wrote:
> Quote from 5.18.2 bytes(3pm)
> If you feel that the functions here within might be useful for
> your application, this possibly indicates a mismatch between
> your mental model of Perl Unicode and the current reality.
> As "how to stop Perl from messing up binary data I'm handling based on
> the misconception that it MUST be text" is a problem I regularly have to
> deal with, I think the "mental mismatch" is rather located on a bunch of
> other minds ....

Hi Rainer,

Perl 6 has read and write to files in binary mode (:bin).
Perl 6 also has a type called "Buf":

I use Buf to read test files where character encoding is
driving me nuts. Perl 6 tries to encode everything it
reads as a string. And no one tries to convert Buf on me.

There are presumably 10E5 different modules implementing something like
this. But Perl already has a builtin data type which is perfectly
capable of handling binary structures/ messages, namely, scalars.

The problem is just that the Perl 5 runtime lacks a way to mark scalars
as "binary" or "text" and that the people who write Perl 5 documentation
suffer from a seriously inflated ego based on a lack of knowledge ---
I've meanwhile come to the assumption that they simply don't believe
that binary data exists. Hence, patronising shit (as quoted above) which
really shouldn't have a place in reference documentation.

The idea that it's ok to break Perl 5 features which have existed for
ages (like using DynaLoader to access individual XS functions) for no
particular reason than "But that's not how I would do it!!" presumably
comes from a similar overassessment of once own importance ...