[TransWarp] Action Plan for the Eradication of Singletons
Phillip J. Eby
pje at telecommunity.com
Sat Apr 26 18:57:17 EDT 2003
Here's what I've decided:
* Default configurations are no more. 'config.iterParents()' will go only
to the root of the supplied component, and no further.
* All 'config' API's related to SystemConfig and AppConfig objects will
disappear. (About 9 functions in all from peak.config.api_impl.)
* The BasicConfig/AppConfig/SysConfig classes will be refactored to form a
single class, 'Application'. 'config.Application' will be set up such that
if you want the default behavior of loading 'peak.ini' and the file
specified by 'PEAK_CONFIG', you get it, but can easily adjust those
behaviors with keyword arguments or by subclassing.
* No changes will be made to the current mechanics of setting or getting
parent components, BUT we will still implement some means for a constructor
to "suggest" to a contained component that the container is its parent.
* Configuration lookups (for properties and utilities) that go past the
root component of the lookup context, will result in a special error
message if the root component doesn't support
'config.IConfigurationRoot'. If the root component *does* support the
interface, then they will behave as they would now upon reaching the end of
the search. (Note that for 'config.findUtilities()' this means that it
will *always* raise the error if the root doesn't support the interface,
because 'findUtilities()' always goes "past the root" in its search.) The
special error message will indicate that the lookup context is not part of
an "application", as its root component is not a configuration root.
* binding.lookupComponent() will not attempt to carry acquisition of
non-URL names "past the root" into the naming system if the root does not
As a result of the above changes, it will be necessary to have a
'config.Application' object (or similar IConfigurationRoot implementation)
in order to use the configuration or naming systems. It is highly
recommended that only startup scripts (e.g. __name__=="__main__"), test
suites, and application servers create 'config.Application' instances, in
order to avoid unintentional duplication of services or divergence of
configuration values. Example usage:
from peak.api import *
app = config.Application()
db = naming.lookup('something', app)
# blah blah
(Okay, so I was impatient and used abbreviations this time...)
I'm still open to using a name other than 'Application'. It may give the
impression that you need to subclass it to create an application. However,
it *would* be safe to subclass it as a basis for an application, as long as
you were sure the component in question would be *used* as an
application. I'm afraid people would go around creating Application
subclasses when they aren't really necessary, and then make an application
out of six Application subclass instances, each of which is going to load
For right now, I'm going to go ahead and start coding with the name
'Application', but I'd like to hear some more input on the subject before
finalizing the name. Some major contenders for the name are 'RootConfig'
and 'ConfigRoot' -- they sound like the interface, and don't sound like you
should subclass them. Maybe even 'config.RootComponent', although that
sounds like maybe you would want to subclass it.
Anyway... if you have thoughts on the name, please speak up.
More information about the PEAK