On 31 Mar, 09:19, jfager <jfa...@gmail.com> wrote: > On Mar 31, 2:54 am, David Stanek <dsta...@dstanek.com> wrote: > > > On Mon, Mar 30, 2009 at 9:40 AM, jfager <jfa...@gmail.com> wrote: > > >http://jasonfager.com/?p=440. > > > > The basic idea is that a language could offer syntactic support for > > > declaring configurable points in the program. The language system > > > would then offer an api to allow the end user to discover a programs > > > configuration service, as well as a general api for providing > > > configuration values.
A configuration "service"? An "end user" that bothers to discover it? API for "providing" configuration "values"? This suggestion, and the companion blog post, seem very distant from the real world for a number of reasons. 1) Users want to supply applications with the least amount of useful configuration information as rarely and easily as possible, not to use advanced tools to satisfy an application's crudely expressed configuration demands. Reducing inconvenience for the user entails sophisticated and mostly ad hoc techniques: deciding without asking (e.g. autoconf looking into C compiler headers and trying shell commands or countless applications with "user profiles" querying the OS for the current user's home directory), asking when the software is installed (e.g. what 8 bit character encoding should be used in a new database), designing sensible and safe defaults. 2) Practical complex configuration files (or their equivalent in a DB, a LDAP directory, etc.) are more important and more permanent than the applications that use them; their syntax and semantics should be defined by external specifications (such as manuals and examples), not in the code of a particular implementation. User documentation is necessary, and having a configuration mechanism that isn't subject to accidents when the application is modified is equally important. 3) Configuration consisting of values associated with individual variables is an unusually simple case. The normal case is translating between nontrivial sequential, hierarchical or reticular data structures in the configuration input and quite different ones in the implementation. 4) Your actual use case seems to be providing a lot of tests with a replacement for the "real" configuration of the actual application. Branding variables as "configuration" all over the program isn't an useful way to help the tests and the actual application build the same data structures in different ways. > > What value does this have over simply having a configuration file. > > "Simply having a configuration file" - okay. What format? What if > the end user wants to keep their configuration info in LDAP? Wait a minute. Reading the "configuration" from a live LDAP directory is a major feature, with involved application specific aspects (e.g. error handling) and a solid justification in the application's requirements (e.g. ensuring up to date authentication and authorization data), not an interchangeable configuration provider and certainly not something that the user can replace. Deciding where the configuration comes from is an integral part of the design, not something that can or should be left to the user: there can be value in defining common object models for various sources of configuration data and rules to combine them, like e.g. in the Spring framework for Java, but it's only a starting point for the actual design of the application's configuration. > > In your load testing application you could have easily checked for the > > settings in a config object. > > Not really easily, no. It would have been repeated boilerplate across > many different test cases (actually, that's what we started with and > refactored away), instead of a simple declaration that delegated the > checking to the test runner. A test runner has no business configuring tests beyond calling generic setup and teardown methods; tests can be designed smartly and factored properly to take care of their own configuration without repeating "boilerplate". > > I think that the discover-ability of > > configuration can be handled with example configs and documentation. > > Who's keeping that up to date? Who's making sure it stays in sync > with the code? Why even bother, if you could get it automatically > from the code? It's the code that must remain in sync with the documentation, the tests, and the actual usage of the application. For example, when did you last see incompatible changes in Apache's httpd.conf? You seem to think code is central and actual use and design is a second class citizen. You say in your blog post: "Users shouldn’t have to pore through the code to find all the little bits they can tweak". They shouldn't because a well designed application has adequate documentation of what should be configured in the form of manuals, wizards, etc. and they shouldn't because they don't want to tweak little bits, not even if they have to. Regards, Lorenzo Gatti -- http://mail.python.org/mailman/listinfo/python-list
