Andreas Raab andreas.raab@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
Hi Daniel,
Okay I give up. There is no chance I can convince you and I can see that the discussion will have no results anyway except from reinforcing existing preconceptions. However,
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.
here is what I wrote specifically to that argument:
However, I can be convinced by the consistency argument, e.g., once the stream decided on a line end convention it should stick to it. Not hard to do, btw, you would only loose some of the "robustness" Ned was talking about. Oh, and modes - you are aware that you can ask a file stream for
the
line end convention, are you?
Cheers, - Andreas
Am Mittwoch, 23.07.03 um 19:39 Uhr schrieb Andreas Raab:
Hi Daniel,
Okay I give up. There is no chance I can convince you and I can see that the discussion will have no results anyway except from reinforcing existing preconceptions.
Seems to me like we need to vote on that? So far, 7 people have participitated in this thread. As far as I can tell the only one happy with the current situation is Daniel. Which could mean we agree to disagree, and just get the change into 3.7a so we can sort out any problems.
-- Bert
Hi all,
On Wed, Jul 23, 2003 at 09:18:12PM +0200, Bert Freudenberg wrote:
Am Mittwoch, 23.07.03 um 19:39 Uhr schrieb Andreas Raab:
Hi Daniel,
Okay I give up. There is no chance I can convince you and I can see that the discussion will have no results anyway except from reinforcing existing preconceptions.
Seems to me like we need to vote on that? So far, 7 people have participitated in this thread. As far as I can tell the only one happy
Ok, so I'll chime in with my Cdn$0.02.
There's an old design principle that goes something like:
Be liberal in what you accept, strict in what you generate.
If we chose to use that as a guide, then the best way to go would be to have the "all singing, all dancing, convert anything to a reasonable string of LFs" applied to reading files opened as text. That's the "liberal" part. For the strict part, on writing a text file we should generate either:
a) the OS standard, or b) the Squeak standard.
If we have liberal input, there is no point to (b), so my vote is for option (a).
To sum up, I think liberal input and OS standard output as the default for text files makes sense. I you need something different, by all means include some switches and knobs to change it, but let this be the default, so users who just want to operate on text without worrying about how the lines are delimited can do so.
with the current situation is Daniel. Which could mean we agree to disagree, and just get the change into 3.7a so we can sort out any problems.
-- Bert
Am Mittwoch, 23.07.03 um 22:35 Uhr schrieb Tom Rushworth:
Ok, so I'll chime in with my Cdn$0.02.
There's an old design principle that goes something like:
Be liberal in what you accept, strict in what you generate.If we chose to use that as a guide, then the best way to go would be to have the "all singing, all dancing, convert anything to a reasonable string of LFs" applied to reading files opened as text. That's the "liberal" part. For the strict part, on writing a text file we should generate either:
a) the OS standard, or b) the Squeak standard.
If we have liberal input, there is no point to (b), so my vote is for option (a).
To sum up, I think liberal input and OS standard output as the default for text files makes sense. I you need something different, by all means include some switches and knobs to change it, but let this be the default, so users who just want to operate on text without worrying about how the lines are delimited can do so.
Very well put. I'm all for it.
-- Bert
Just for other outside information. Apparently the Python group has been struggling with this issue. I normally don't read about Python, but occasionally take a peek. :)
This PEP has been implemented and is in the latest Python.
http://www.python.org/dev/doc/devel/whatsnew/node7.html
Talks about the problem and how they decided to handle it for Python.
Personally, I'm for handling it as elegantly and transparently as possible. I think that is what most people will expect. I understand Daniel's position. However, Squeak is a high-level environment. Low-level options are there, but I believe most people expect intuitive responses. I don't expect to open a text document written on the platform I'm using Squeak on and Squeak not handle it properly.
This happens on files created by and on the platform OS Squeak is running on. No mixed up line endings.
Nevertheless, I do believe Squeak is its own platform and consistency on that platform is the most important.
I like the Liberal in Strict out.
Jimmie Houchin
Bert Freudenberg wrote:
Am Mittwoch, 23.07.03 um 19:39 Uhr schrieb Andreas Raab:
Hi Daniel,
Okay I give up. There is no chance I can convince you and I can see that the discussion will have no results anyway except from reinforcing existing preconceptions.
Seems to me like we need to vote on that? So far, 7 people have participitated in this thread. As far as I can tell the only one happy with the current situation is Daniel. Which could mean we agree to disagree, and just get the change into 3.7a so we can sort out any problems.
-- Bert
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Daniel Vainsencher -
Jimmie Houchin -
tbr＠mannynkapy.net