Thoughts on language-level configuration support?

[jfager]

On Mar 31, 3:40 am, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> On Mon, 30 Mar 2009 23:06:50 -0700, jfager wrote:
> > On Mar 30, 9:31 pm, "Rhodri James" <rho... at wildebst.demon.co.uk> wrote:
> ...
> >> This would be a interesting idea, but ultimately no more than a veneer
> >> over the current set of configuration possibilities.  Quite how such a
> >> system would tell whether to get configuration data from command line
> >> parameters, a config file somewhere, or just pull bytes off the Z-wave
> >>  from Mars, I'm not at all clear.
>
> > Not a veneer over; a foundation under.  As I acknowledged in my blog
> > post, this would require a small bit of bootstrapping, to configure
> > which end-user configuration system was used.  But this would simply
> > point to an adapter, that would map from the desired configuration
> > interface into the canonical standard api provided by the language
> > system.
>
> Let's talk about a practical example. The ls command has the API that the
> "-l" switch means "show me long options". You're suggesting that users
> should not interact with the user-interface, but directly with the
> implementation.  You are, essentially, assuming that there is a one-to-one
> correspondence between data that the user inputs and variables in the
> implementation, and that users can understand the implementation.

No, not at all.  I'm saying that the programmer shouldn't have to care
what the end-user's interface is, not there's no end-user interface at
all.  For the program 'ls', why should I, the programmer, care at all
how the end user actually specifies that they want 'long options'?  I
might think or know that a command line argument is the 'best' way,
but why should I even worry about it?  I should just tell them that
option exists, and then they can choose how to give me a value for it
in whatever way they please.



> But that's not necessarily the case. The switch -l might affect a dozen
> different variables. So instead of the user needing to learn *one*
> command line option (or click on one checkbox in a GUI, or whatever), you
> expect him to reason "I want to see a long display of my files, so I need
> to set the value of line_width to 47, date_style to 3, show_perms to
> True, and format_into_columns to -1".

Not at all, not even a little bit.  Why wouldn't you just say some
variable 'long-lines' is configurable, and then use that to do all the
work you would have done by manually parsing the command-line
arguments for the -l flag?  You, the programmer, still have complete
control over what is or isn't visible to the end user, it's not like
I'm advocating that every variable in the system automagically become
end-user configurable without programmer input.


> I don't think that's going to fly. Separation of interface and
> implementation is a Good Thing.

Agreed, that's the whole point of this.  Use the interface provided by
the language, then let the end user provide their own implementation
(of course, there will be basic ones provided out of the box) of how
to specify their configuration values.


>
> Or consider another scenario:
>
> def ls:
>     if '-l' in sys.argv:
>         file_iterator = SimpleFilenameWriter()
>     else:
>         file_iterator = DetailedFilenameWriter()
>     #...
>
> Under your proposal, the user would somehow have to create the
> appropriate instance and feed it to your program. That's simply not
> practical! So you still need some sort of proxy variable, virtually
> identically as you do now:
>
> conf make_long_list = True
>
> def ls(optionlist):
>     if make_long_list:
>         file_iterator = SimpleFilenameWriter()
>     else:
>         file_iterator = DetailedFilenameWriter()
>     #...

This second one is what I intended (no optionlist param needed,
though).  I'm curious - why do you think this is a bad thing?  One toy
example looks pretty similar to how you would do things now, and
you're ready to throw out the whole concept?  Notice that you did
actually gain something that I think is significant - you no longer
have any hardcoded reference to the fact that make_long_list is
defined as a command line parameter.



>
> > The problem with the current set of configuration possibilities is that
> > there's nothing really constant between them, unless the programmer
> > explicitly codes it, even though they're basically accomplishing the
> > same thing.  There's nothing amazingly special about this proposal, it's
> > just saying:  that basic thing that we do in a lot of different ways,
> > let's make as much of that as possible standard.
>
> Over-generalization actually makes things more complicated. I think
> you're over-generalizing.

Keep throwing out examples of where this makes things more
complicated, it's good to work through all the concerns.



> >> You've just specified a different way in which you have to do this, one
> >> that's a good deal less visible in the code
>
> > Why would it be less visible?  If it's syntax, you would know exactly
> > where it was just by looking.
>
> It could be *anywhere* in your project. It could be in some random
> library that you imported, and the user discovers that they can modify
> variables you didn't even know existed.

If that's true, it's because the developer consciously said at some
point, "This needs to be configurable".  And I, as an occasional end
user of software products, would sometimes love to find I could modify
variables I didn't even know existed.  Discoverability is a good
thing, much better than having a potentially useful knob hidden away
behind stale documentation or buried deep in source code somewhere.



> > Actually, you get the best of both worlds.  You get to see clearly in
> > the code how the configured values are actually used, and you get the
> > gathered summary of configurable values from the "discoverability"
> > implementation.
>
> I've learned to distrust "discovery", ever since I learned that my
> doctests, which were supposedly all running without error, in fact hadn't
> been discovered at all, and not one single test was running. So even if
> you could get this working, I'd be luke-warm on the idea.

I don't know what to say to this, except that it seems like the
penalty for missing something in the discovery phase of what I'm
proposing would be either less dangerous or more obvious, less
dangerous because the program would just fall back to a default and
continue on (you didn't come across some variable you didn't even know
existed), more obvious because you might be expecting to be able to
configure something specific, or because possibly no value would be
provided and an error would be thrown.


- Jason

>
> --
> Steven