Extending FileList with CrLf

Daniel Vainsencher danielv at netvision.net.il
Wed Jul 23 09:16:29 UTC 2003


Andreas Raab <andreas.raab at gmx.de> wrote:
> With which I strongly disagree. I'll take apart just one of your arguments:
> > I emphatically disagree - this would be even worse. Should an image
> > reading program, when detecting a corrupted jpeg image, try to interpret
> > the rest of it a BMP?
Well, if you really feel you can pick and choose, you might as well
choose an argument, not an illustration.
 
> As with many of the arguments you are making in this thread this is wildly
> over the top. A more reasonable comparison ...
No comparison is a replacement for an argument. That A did it doesn't
mean it is reasonable when B does it. The question is should the
behavior of Streams be symmetric for reading and writing, or "robust"
and on that you've made no arguments, and replied to none of mine.

But addressing your comparison while I'm at it, you may note that while
ImageReaderWriter is explicitly smart about detecting formats, it can
not (AFAICT, not very familiar with that code) directly be used to write
forms to files - to do that, the application needs to choose a subclass
corresponding to a format. The application needs to make that decision,
the stream shouldn't. It is ok, however, for JPEGReadWriter to read and
write JPEG formats, without asking the application. However, I would
find it most confusing if JPEGReadWriter, on encountering a BMP, didn't
bring up an exception. In the same way, specific stream classes can 
A. Represent a specific encoding, and stick to it for reading and
writing, or 
B. Do detection, but not be usable for writing without specification of
encoding.

It is an issue of symmetry of expectation between reading and writing.
Beyond the effects of the assymetry being very confusing and unexpected
(as I argued in my response to Ned), in my eyes, this assymetry is also
ugly, though I guess that might be a matter of taste.

> > Streams should not try to "detect" line endings.
> Why not? That's just what you were saying is great about Emacs.
EMACS is an application. Something that is a feature in an application
can certainly be a bug in a low level class library. If you're asking
"why not", then obviously we are not communicating at all. Again.

Daniel



More information about the Squeak-dev mailing list