Extending FileList with CrLf

Andreas Raab andreas.raab at gmx.de
Sun Aug 3 10:47:49 UTC 2003


Hi Colin,

> That said, here's what I mean:

Thanks for the clarification. I wasn't sure if you had read the thread in
all it's g(l)ory detail ;-)

That said, your argument about package removal being intrinsically tight to
the amount of "smartness" one can put into a "library" greatly disturbs me.
That's for two reasons. For one thing, it ultimately comes down to the point
that if we always have to assume the lowest common denominator we'll be
unable to introduce any higher-level abstraction (which, naturally, imply
some "smartness"). In a sense, your arguments can be interpreted as that
every application _should_ have to implement the smartness by itself.

Secondly, even in the "package age" we can still get a reasonably good
feeling about what most clients expectations are merely by loading the
packages. So while you are right about "fixing" them being an unreasonably
complex problem, it is quite possible to look at them, understand them, and
choose sensible defaults for them. Given that today most "applications" are
plain broken when it comes to handling text (as almost all of them simply
convert line ends into garbage) it seems that it may be a better default to
have a general smart, auto-translating default.

Of course, you are welcome to disagree, but now I'm out of this thread for
real ;-)

Cheers,
  - Andreas

> Yes, I do want Monticello to handle line-ends gracefully, to be smart 
> about deciding which line ends to use and translate as needed, 
> transparently to the user. That doesn't mean I want 
> StandardFileStream to handle all that for me.
> 
> MCFile *implements* a smart, auto-detecting, default-to-platform 
> line-end policy, it doesn't rely on one. That policy is specific to 
> applications that deal with CVS-managed text files on a variety of 
> platforms and with a variety of CVS clients. I wouldn't want 
> or expect that policy to be implemented by a general-purpose FileStream.
> 
> Daniel's argument hinges on the distinction between applications and 
> libraries. In the days of yore, that wasn't particularly meaningful. 
> But as the package removals progress, we must begin to think 
> about the base image as a common set of libraries used by many
> applications.
> 
> In a monolithic system, it makes sense to put "smarts" into 
> the stream classes. After all, you've got all the users of those
> classes handy, and cmd-n will tell you everything that needs to be 
> accommodated by the policy.
> 
> But a library shouldn't try to be smarter than the application that 
> uses it. And yes, I know that the smarts can be turned off. 
> But I agree with Daniel that the errors caused by inappropriate
> cleverness are worse than those caused by lack of cleverness.
> Cleverness adds complexity, and when something goes wrong it's that
> much more difficult to figure out what it was. Therefore, I believe
> the default should be simple behaviour (dumb), rather than complex
> behaviour (smart).
> 
> That's all I have to say.
> 
> Colin
> 
> 



More information about the Squeak-dev mailing list