On Wed 21 Jul, Lex Spoon wrote:
> Man, referencing CrLfFileStream directly doesn't make sense if it's alraedy the defaul
> t.  If it's the default, what you want to do is swap between using ascii mode and bina
> ry mode.  Binary mode makes no changes, and ascii mode does lots o
> f nice but safe changes.  This all works perfectly, precisely as long as you accuratel
> y set the mode on the stream.  (And don't change it midstream)
But CrLfFileStream _isn't_ the default. Maybe it should be, or maybe the
functionality ought to be pushed up to FileStream. Or more likely we should
sit back, think about it and refactor the FileStream hierarchy. It's
a little messy at the moment, with a pseudo-abstract class having several
sort-of concrete classes below it and a somewhat messy set of instance
creation messages; I posted some suggested minimal fixes for that
particular problem a few days ago precisley because I found a bug caused by
a dired reference to CrLfFileStream.

In the twenty years or so of programming I've done, including fifteen or
more of Smalltalk and a couple as the manager of Smalltalk development at
PPS, I've had my face repeatedly rubbed in the fact that it is difficult to
get major changes accepted but reasonably easy to get small fixes emplaced.
Thus I explained the problem, offered a small fix pro-tempore and suggested
the possibility of a better solution. And yes, I did think about using
CrLfFileStream as the concreteStream and rejected it.

If people like to try out my 'trivial and partial fix' to see whether they
find it of some benefit then we can consider whether there is enough
interest in a fuller and more thorough solution, perhaps even the
FileStream refactoring I mentioned.

-- 
Useful random insult:- Cursor's flashing but there's no response.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>