Front page | perl.perl5.porters |
Postings from March 2012
Mark Jason Dominus <mjd@plover.com> wrote on Sun, 04 Mar 2012 04:53:50 EST:
> Suppose it were a fatal error to read from a multibyte-encoded string
> while $/ was set to a number. What would be wrong with that?
Good question.
Alternately, what would be wrong with treating
binmode(FH, ":utf8");
$/ = \500;
$var = <FH>;
much as we currently do
binmode(FH, ":utf8");
read(FH, $var, 500);
That is, just send it through the current layer, which deals in characters
not bytes. If I'm remembering correctly, even sysread() does so, somewhat
bizarrely enough.
The whole reference-to-integer-bytes assignment to $/ seems like too much
tricksiness for its own good. In hindsight I wish a functional interface
had been provided instead of a tricksily-named variable interface.
A talented Python programmer of my acquaintance, and one not unfamiliar
with nor at all down on Perl, either, recently said this to me:
There seems to be a difference of approach between Perl and
Python. In Perl the approach seems to be to add anything
which might be useful and TIMTOWTDI, whereas in Python the
approach is not to add anything until there is a proven use-
case for it in order to avoid bloating the language.
What he says really comes home here. Carving out another corner fo the
language for yet another special exception via a punctuational short cut
that I don't think we needed. It been one of the things that's always met
with disapproval, as much 20 years ago as today. A functional interface,
something with a real name to it, would have been better.
Teaching Perl to beginners these days, anything that gets at filehandles
through magic global variables instead of through method calls on
IO::Handle objects comes off as painfully confusing to them. To be honest,
I don't even try to teach $| any more. It's not worth the cognitive load.
--tom
Thread Previous
|
Thread Next