Dan Kogai <dankogai(_at_)dan(_dot_)co(_dot_)jp> writes:
eval {
binmode IN, ":utf8";
binmode STDIN, ":utf8";
binmode STDOUT, ":utf8";
};
I am not going to yell at something already fixed but I can't keep
grumbling this new use of binmode sucks. Reminds me too much of DOS.
We have to keep binmode for a while as that is what Camel-III describes.
But we could make it an alias or wrapper on something better if we
can agree what would be better.
Overloading it is slightly problematic in the implementation as well.
The _worst_ mess in this area is the :raw pseudo layer - which I think
needs a careful reading of what we have commited it to mean and a re-write.
Pre-perlio on CRLF platforms one got CRLF unless one said binmode().
Then we added :crlf as a "layer" (aka discipline) which makes a kind of
sense - but then added :raw which is an anti-layer. 'raw' has very
extream connotations to me. In one sense it is okay : raw == !cooked
which is fine if you can only "cook" something one way, but with
perlio you get a choice (boiled, roasted, grilled, braised and
rare,medium,well on top.
It may have been
better in hind-sight to have gone for :newline("\x0d\x0a") vs
:newline("\x0a").
So a "clean" interface would have some kind of ioctl() like mechanism
to "configure" existing layers - e.g. to turn on/off CRLF<->\n mapping
in :crlf layer.
The Win32 fails on the Encode/t/JP.t at present are due to entangling
of :encoding() and CRLF issues.
Part of the snag is it is not clear where CRLF mapping should be done
in the layer stack. Traditionally on Win32 etc. it was done right
at the bottom in read()/write() - but for perl one can make a case for
doing it right at the top just under (or in) sv_gets().
Ilya argues that POSIXy TTYs can do CRLF type translations (i.e. below
bottom - in STREAMS modules!)
So layer concept works well and we have some useful layers, but interface
for manipulating them is not rich enough...
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
