I have the impression (by following the discussions from afar, mind 
you) that:
- some people need very specific support, mainly for compatibility 
reasons. So they need to be able to absolutely specify a certain 
policy, and are not helped by any kind of 'smartness'; that just spells 
trouble for them. Currently they have to patch and shortcut stuff in 
different places to let their stuff work.
- a lot of other people want a forward-looking solution that just opens 
their files. Smart is good, in that context.

The reason that the discussion goes back and forth is that you cannot 
settle on a default, since people need it for two different things, and 
that both are valid applications. In order to move forward with this 
whole discussion I propose to stop trying to convince each-other that 
one solution should be the default (which will not work or, if it 
works, will upset the losing party), and to find a way to have both 
solutions.

The only technical solution I see for this is to have an abstract class 
that implements most of the things that you want, a 'smart' subclass, 
and a 'fixedPolicy' subclass. Of course that is the naive solution, but 
something along these lines could work. Then:
- by default clients get the smart solution (since I think more clients 
are interested in the 'smart' than the 'specific' translation; if not: 
switch).
- clients can directly change to the 'specific' solution. The key 
difference with the current situation is that, in order to do so, they 
do not have to circumvent and shortcut a lot of things in order to do 
so. They have a nice subclass to specify their policy (or configure an 
existing one).

Is this womhow reasonable, or did I completely miss the point?

On Sunday, Aug 3, 2003, at 12:47 Europe/Zurich, Andreas Raab wrote:

> 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
>>
>>
>
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org