> Because it is the wrong thing for a library to do?

You see, that's exactly the reason why I said that this discussion is going
nowhere. You are simply convinced that this is "the wrong thing to do" and
no arguments or examples will convince you otherwise. This discussion is
simply pointless and I won't waste my time with it.

Cheers,
  - Andreas


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Daniel Vainsencher
> Sent: Sunday, August 03, 2003 1:26 AM
> To: The general-purpose Squeak developers list
> Cc: 'The general-purpose Squeak developers list'
> Subject: RE: Extending FileList with CrLf
> 
> 
> Andreas Raab <andreas.raab at gmx.de> wrote:
> > Daniel,
> > 
> > Sigh. When will you actually start listening to what is 
> said by all the
> > people involved in this thread? 
> I am listening, though I do agree at least some misunderstanding is
> going on in this thread.
> 
> > Every time you write one of those "don't
> > define a policy across all application" thingies you imply 
> that clients are
> > unable to change the policy. 
> No I dont. Of course any squeaker and any squeak application *can*, in
> some way, and maybe even quite simply, cause squeak to behave any way
> they want. That is one of squeaks endearing qualities.
> 
> > How often has everyone to repeat that this is
> > simply false? 
> Zero. Nobody is claiming it.
> 
> > Defining a _default_ policy does not mean that any application
> > which cares cannot change it. 
> Of course. The default policy should be the one that causes the least
> painful surprises. I claim that while system line-end auto-conversions
> would remove some surprises, they would create more, and more painful
> ones.
> 
> > The point about defaults is to capture the majority of use cases. 
> No, the point about defaults is for them to be sensible. While most
> programs that want to read text don't care about line endings 
> are being
> used, it is still not sensible to make autoconversions the default,
> *because conflating two different abstractions is bad practice*. It is
> still wrong for the class library to decide on line ending conversions
> by default, because the common abstraction for text does not specify
> line ending semantics, but lets programs and platforms do so, and many
> do have an opinion on it. This means that control of this 
> issue belongs
> explicitly with the applications, by default. 
> 
> > And deny
> > it as long as you want, in the vast majority of the cases 
> where we deal with
> > text, we _want_ a smart translation of line endings.
> Same thing from another perspective - autoconverting stuff loses
> information. I agree that sometimes this specific information is
> meaningless, but sometimes it is meaningful. The cost of erring in the
> two different directions is not the same. If you think it is, and that
> mangling endlines indiscriminately is fine, then you're forgetting how
> many peoples questions we've had to answer saying "your 
> download client
> thinks that line ends should automatically converted". Therefore, make
> the safe setting the default, and let applications that know 
> that their
> formats are lineending oblivious say so explicitly. 
> 
> > Sure, every
> > "application" could set this on its own, but then, why not 
> just make it the
> > default.
> Because it is the wrong thing for a library to do?
> 
> > This is really silly. We're repeating the same arguments 
> over and over.
> No, we're not. Yours are changing - in your last reply you compared
> EMACS to a library and compared the streams to 
> ImageReaderWriter (which
> is a reasonable exemplar of what I'm suggesting). I am also 
> refining my
> position - I thought for a while that I am being obnoxious over
> something I invented. Alas, now I know that C and Python do what I
> suggest. The scheme standard also waffles on this as does Smalltalks,
> but mit-scheme at least has only the OS-compliant conversions, which I
> can live with, but is somewhat primitive. 
> 
> I might not call this progress, but we're not in a fixed point :-)
> 
> But lets try to accelerate this to root out the precise differences.
> What do you disagree with?
> 1. There are two separate useful abstractions - "line endings" and
> "autodeciding line endings", which one might want to use 
> separately (one
> might want to read a file with a specified file ending, without
> autodetection).
> 2. Text, in the wide world, is not uniformly defined as 
> giving the same
> meaning to cr/lf/cr+lf.
> 3. If squeak provides a non-standard abstraction, the interface to it
> should hints at its semantics.
> 
> Daniel
>