[TransWarp] Open issues/design questions for 0.5a1

[Phillip J. Eby]

These are design questions that must be answered, or open issues that must 
be addressed, before 0.5a1 is released.  I'm aiming for a release by this 
weekend, so if you have input on any of the below, be it question, 
suggestion, or objection, please let me know immediately, as I will be 
making final decisions and starting implementation on these tomorrow 
(Wednesday).  Thanks.


* What should the default implementation of config.IConfigurationRoot be 
called?  Current candidates include "Application", "DefaultContext", 
"RootConfig", "ConfigRoot", "ConfigurationRoot", and "RootConfiguration", 
but it may be that the best name hasn't been thought of yet.

My leaning right now is towards "DefaultContext", because in a sense it is 
the intended use of the object.  In explaining it to someone, I might say, 
"configuration objects such as utilities and properties are looked up in a 
component's context.  For a given set of components (such as those that 
make up an application, you will generally want to have a "default context" 
that supplies most of the configuration.  The easisest way to do this is by 
having an instance of 'config.DefaultContext' as a root component above 
your application components, e.g.:

     ctx = config.DefaultContext()

     myApp = MyAppClass(ctx)

Anyway, that's my reasoning for now on this one.  If anybody has any better 
ideas, please let me know.


* Argument order to configuration-related APIs.  Currently, 
naming.lookup(), config.findUtility(), config.getProperty(), 
config.findUtilities(), binding.lookupComponent(), and perhaps several 
other APIs whose names escape me at the moment, all use the argument order:

     thingToLookup, placeToLookForIt

We changed to this argument order because until this past weekend and the 
"explicit roots" refactoring, 'placeToLookForIt' was optional.  Now, it's 
mandatory.  Should we change the order back?  I'm about -0 on this, because 
if both arguments are mandatory, what difference does it make?  But, this 
order is inconsistent when compared to 'config.setPropertyFor()' and 
similar APIs, which take this argument order:

     placeToSetIt, thingToSet, valueToSetItTo

Also, all binding component constructors take a context (parent component) 
argument *first*, and there are also some API's that take *only* the 
context argument (e.g. storage.beginTransaction()).  This sort of swings me 
up to +0, maybe +0.5.  It sure would be nice to have virtually everything 
in PEAK that's not a method of some object, consistently take a "context 
component" as their first parameter.  It would mean not having to think 
about it, and would therefore be more Pythonic (in the sense of not making 
you stop your work to think about irrelevant details).  The downside is 
going through the code, both that of PEAK itself, and any code that you 
guys have written for it to date.


* What attributes should be part of the interface of activatable 
descriptors? (e.g. Once and other bindings).  Currently this ad-hoc 
hodgepodge includes '_provides' and 'activateUponAssembly'.  This probably 
needs to be formalized as an interface.