Hi Guys,

Rather than spending my time with fruitless discussions about why it's the
right or the wrong thing to have CrLfFileStream be the default I decided to
spend a bit of time hacking a higher-level solution addressing various of
the problems involved.

The package is up at SM now:
http://map1.squeakfoundation.org/sm/packagebyname/TextFiles
with documentation at the Swiki
http://minnow.cc.gatech.edu/squeak/3342

Some notable features:
* Provides buffered operations for efficiently reading and writing large
files
* Supports automatic line end conversions
* Provides a framework for various encodings such as ISO-8859 etc.
* Polymorphic with FileStream so you can create a TextFile just the way you
would create a FileStream
* Usable with internal as well as external streams, so you can convert text
representations within Squeak too
* Supports 'chunking' to index files containing chunks of text more
efficiently

>From a conceptual point of view TextFile renders FileStream as a low-level
I/O device (very much like a Socket) with very few required responsibilities
- in fact, so few that TextFile could even implement the file primitives but
doesn't for the added advantage of being able to operate both on internal
and external streams.

Personally, I think that in the long-term we should remove CrLfFileStream
alltogether in favour of TextFile, as it is (supposed to be) a high-level
abstraction for handling text and it will (hopefully) reduce the need for
the ridiculous kinds of discussion we've seen over the last days. With
TextFile you have an explicit abstraction; now all that remains is to fix
about every other user of FileStream to use TextFile instead of the
low-level i/o device ;-)

Cheers,
  - Andreas

PS. With a little bit more work, TextFile can probably be made to work on
SocketStream too.

PPS. I would've called it "TextStream" but that name was already taken ;-)