FileStream and TextConverters etc (reposting from another thread)

Andreas Raab andreas.raab at gmx.de
Tue Apr 11 08:04:01 UTC 2006


See http://minnow.cc.gatech.edu/squeak/3342

Cheers,
   - Andreas

PS. The above is a way of saying KISS. [Standard|CrLf|MultiByte] 
FileStream is *heavily* overloaded with lots of dependent 
responsibilities and the best way to deal with these issues top to 
bottom is to refactor the dimensions somewhat - for example by making 
"text writing" (lf conversion, encodings) an independent dimension from 
"byte writing" (file i/o).

goran at krampe.se wrote:
> Hi!
> 
> I decided to repost this bit below since I think most people missed it
> (it was in the SqueakMap thread):
> ---------
> Btw, yesterday I was staring at the MultiByteFileStream stuff and...
> well, IMHO it would have been better *for me* (other users may have
> other stories to tell) if the default was binary and not ascii. The
> principle of least surprise. If I open a filestream and don't tell it
> *anything*, then I would expect it to just feed me the bits and bytes -
> as Strings or ByteArrays, but not doing any conversions or line end
> mumbo jumbo or any other non expected "nice things". An example of this
> is inspecting a file in the file list - I really appreciated the fact
> that filelist didn't do *any* conversion on the stuff it showed me - now
> it does. And I also wonder where the hex view went... anyway:
> 
> Yesterday my collegue wanted to save stuff with platform specific line
> endings (wantsLineEndConversion: true etc) but NOT doing any other
> conversions. We realized that you can't set converter to nil - it will
> lazily set itself to the default platform converter (seems to me at
> least). And if you tell the stream to be binary it will not do line end
> conversions.
> 
> What I ended up doing was creating NullTextConverter (which does no
> conversion at all, trivial to write) and then it worked fine. It seems
> to me that a
> cleaner approach here would be to:
> 
> 1. Do line end conversions or not regardless of the 2 choices below..
> 2. Binary or ascii - only decides if we use ByteArrays or Strings,
> doesn't concern conversions or line ends.
> 3. Selection of converter where we also have a NullConverter that does
> nothing.
> 
> IMHO (having not dissected this in total detail) the above three options
> should be combinable. So for example, in our case we have utf8 strings
> that we want to write out *as is* and use #cr to get platform specific
> line endings.
> -------------
> 
> I also think that a default FileStream should not do any line end
> conversions or conversions at all by default (but still use Strings
> instead of ByteArrays). In other words - I would like the "least
> surprise" principle to hold. Am I alone in this idea? I love the work of
> Yoshiki and friends in this area - I just want to iron out the small
> "gotchas" with it.
> 
> Now, Yoshiki and all the rest of you - feel free to correct me with the
> real facts. :)
> 
> regards, Göran
> 
> 




More information about the Squeak-dev mailing list