[Swift-devel] Issues to resolve for the 0.96 config mechanism

[Mihael Hategan]

Inheritance is nice and we want that. It's there, not going away. But it
is being made explicit rather than implicit. In an OO language it's the
same as saying that if you inherit from a class, you need to tell the
compiler what the class is instead of only allowing classes whose names
start with B to inherit from classes whose names start with GRZ who in
turn can only inherit from a class called BLA, and you don't get to say
which; the compiler automatically picks them for you.

The five step path is logical and I too can come up with scenarios where
it would be needed. I can also come up with scenarios where something
else is logical, and there are examples of scenarios in which a
similarly stepped path is a problem. 

So I think we are arguing very different things here. What I do not like
is lenient defaults. Like $PWD/swift.conf. If the user creates a file
siwft.conf, Swift will happily run. The user will probably only notice
it after a lot of work and pain. Similar story with
~/.swift/swift.properties. But I have never heard one person complain
that they have to say -sites.file on the command line. 

On Sun, 2014-07-13 at 20:04 -0500, Tim Armstrong wrote:
> My two cents: the five step search path seems logical and I can come up
> with scenarios where someone would want to have a particular setting at a
> particular level in the hierarchy.
> 
> It reminds me though of some of the OOP debates about inheritance, where
> you have carefully thought out, deep, inheritance hierarchies, carefully
> engineered to reuse code wherever possible.  The problem tends to be that
> as a developer reading a bit of code, you've got no idea which overridden
> method is being called, except maybe with the help of an IDE.  There's not
> really a right answer, just that sometimes the smart complicated way is the
> best, and sometimes the dumb but simple way is the best.
> 
> Maybe if having 4/5 levels of configuration is "the right thing" that users
> should do, all of the sample and tutorial properties files that users will
> copy could just explicitly include their predecessor?  I.e. use the
> explicit mechanism but encourage the desired approach by convention.

The "desired approach" here is our interpretation of the feedback we got
from the users. I don't think we should encourage them to do what we
think they said they want to do. They probably know better.

> 
> With the more complex inheritance mechanism, it seems like it is almost
> necessary to have a tool that shows all of the currently applied settings
> and where they come from.

I agree. This is currently in the log, but it can be better.

Mihael