[TransWarp] PROPOSAL: Namespace unification: binding, naming, config

[Phillip J. Eby]

While working on finishing the design of PEAK's configuration system this 
weekend, it occurred to me that there was a distinct similarity between 
three kinds of trees in PEAK: binding.Component trees, naming.Context 
trees, and config.Stack trees.  All involve some type of "inheritance" or 
"acquisitional" context.

It occurs to me that there isn't any reason for naming.Context objects to 
use a separate "environment" or "configuration" parameter.  They could just 
become binding.Components themselves.  Although by default, 
binding.Components are only instantiated as named attributes of their 
parent component, they will work just fine as an independent object that 
just has a pointer to a parent.

Similarly, although we've been talking about the configuration stack as 
though it were something that lived outside the component tree, it 
similarly could live inside it... as a kind of default root object for 
components which do not otherwise have a parent.

And coming full circle, the binding system doesn't need to pass a 
configuration object or parameter to the naming system in order to tell it 
where a lookup is relative to; it can just bind the initial context object 
as a child component of the component.  Heck, objects can freely keep 
around an initial context object bound to themselves, if they want; they're 
not very heavyweight.

What we end up with, instead, is a simple interface, something like 
getConfigSetting(propertyname), that's available on all 
binding.Components.  The default implementation would look things up in a 
dictionary associated with the component, and if not found, delegate the 
inquiry to the parent component, unless there is none, in which case 
request a lookup of the default configuration object, and delegate to 
that.  Components at each level can potentially cache their response.

In practice, I think it'll actually need two methods, one for the 
"external" interface, with schema checking and handling of defaults, and 
one for the "internal" interface that handles the delegation, wrapping 
return values with an audit trail to monitor the origin of the 
configuration setting, and caching.

All of this brings up a new and interesting possibility: "style 
sheets".  Think of how CSS defines properties for the components of a 
document tree, with selectors that identify an object by class, ID, or 
context relative to other objects.  The "unified tree theory" of PEAK would 
let us define a similar mechanism, but the properties could be literally 
any configuration property at all.  And the same mechanism could be used as 
a style sheet for a GUI application, as a set of business rules for 
security or workflow properties in a hierarchical context, or just about 
anything else.

I haven't given much thought to this style sheet idea as yet, and I don't 
plan on trying to have it all figured out before implementing a basic 
configuration-acquiring interface.  But I do want the initial system to 
support a very limited sort of "pushing" of configuration settings: a 
component should be able to define a binding for one of its attributes that 
specifies bindings for parameters of the child object.  Right now, the only 
way to do this is to subclass the child object as a nested class in the 
parent object's class.  It would be nice to be able to specify 
configurations that will apply, regardless of the actual class that ends up 
filling the spot.  This is important for the naming system in particular, 
where the exact class of Context object is not going to be known ahead of 
time, even though the component that needs the context knows what settings 
it wants to supply to that context.