Hi Daniel,

Daniel Vainsencher wrote:
<..>
> In short - we should have Streams that can be in binary mode or in text
> mode. In text mode, they should be able to apply whatever
> transformations the application requests it to. Streams should provide
> only mechanism, and zero policy at all about encodings or
> transformations.

I see your point, but this way it doesn't make sense to me. To make 
sense we should have
- streams are binary
- a transformator (no, that's not the right word, I guess) may be
   attached to a stream, with some predefined
   e.g. #crLineEnding would interpret the data as lines using cr
        #autoDetectLineEndingToLF would autodetect lineEndings, and 

                                  convert them to lf
   or, if you like to get fancy
        #lineEnding: '<br>' convertTo: crlf

> Stream creation protocol could be changed to have #binaryFileNamed:
> #crTextFileNamed: lfTextFileNamed: platformTextFileNamed: and maybe,
> just maybe, autodetectEncodingOldFileNamed:. But oldFileNamed: should
> not decide on its own to do mappings without the application having a
> clue about it.

Still, I'd vote for autodetection as the standard 'transformator', and a 
#lineEnding message to which the stream would answer the lineendings 
found in the stream.

For text files _I_ don't care about line endings, most of the time 'read 
whatever you get, and write it in a (however) defined way' is what I 
want, of course _sometimes_ I want to use special lineendings, but so 
far noone opted to disallow it.


Kind regards,

Ingo