Re: operator overloading
On Fri, 9 May 2008, Lew wrote:
Tom Anderson wrote:
Much or most of the standard library is indeed pretty good. There are
patches where it's not, though - J2EE, XML, Swing. I often feel like i'm
Those are three areas where Java libraries really shine, actually.
No.
jumping through hoops with java.io, but only when trying to mix
readers/writers and streams.
java.io is pretty straightforward. What troubles does it cause you?
Normally one would want to avoid mixing Readers/Writers with Streams.
The secret to getting them to work together is encoding. One can hardly
blame the Java API for dealing with such a complex matter and (oh,
horror) letting some of that complexity be visible to the programmer.
I'm not convinced it does it in the best way possible.
I think i was doing something where i needed to be able to read lines of
text, but also things in binary, from a stream. To read lines, you need a
BufferedReader, and to read binary data, you need a DataInputStream; you
can wrap the BufferedReader round an InputStreamReader, and wrap that
round the DataInputStream, or whatever stream underlies that. But then you
have a problem, because the BufferedReader is eating more the data than it
should. DataInputStream has a readLine of its own, but it'd deprecated and
doesn't do character encoding.
More generally, i just don't see why there needs to be a Reader/Writer
hierarchy that parallels the InputStream/OutputStream hierarchy. Why not
just have a Reader, which wraps an InputStream and does decoding, and a
Writer, which wraps an OutputStream and does encoding? The Reader would be
able to read lines, but only if on top of a PushbackInputStream. That
would have solved my problem in a trice.
I guess there's a case for StringReader/StringWriter too. But not the
File/Buffered/whatever ones. Byte streams can provide those facilities.
tom
--
Heinlein has done more to harm SF than has any other writer, I think. --
PKD