[PEAK] FYI: bug in binding.Component and config.ConfigMap

[Phillip J. Eby]

At 12:33 AM 8/30/04 -0400, Phillip J. Eby wrote:

>This problem only occurs when *no* providers of any kind have been 
>registered with the component instance.  At some point I put in some code 
>to avoid "unnecessarily" creating a configuration map for individual 
>components during lookups.  This "saves" creating a configuration map for 
>every component, at the cost of a possibly inconsistent configuration view.
>
>Unfortunately, the fix is high-impact: changing it to the correct behavior 
>may significantly increase memory consumption for binding.Component 
>subclasses.  It will also slow down some configuration lookups.  And 
>finally, it will break code that relies on the current behavior.

I found a better way to fix this, which is now implemented in CVS.

Instead of having 'binding.Component' always instantiate a ConfigMap (which 
is what would have caused the increased memory use and slowdowns), I've 
created a new class, 'binding.Configurable', which must be used if you want 
to be able to register configuration providers at runtime (as opposed to 
class definition time).

The downside to this is that any Component subclasses you have now that are 
dynamically configured will break after this update.  But, they should 
break cleanly, visibly, and every time, because they'll be missing the 
'registerProvider()' method, or won't adapt to 'config.IConfigurable'.

So, if you get this error with a given class, change its base class to the 
new 'binding.Configurable' class, or if it derives from another 'Component' 
subclass, just mix 'Configurable' in to the class that needs it.  For 
example 'web.ResourceDirectory' derives from 'web.Resource', which derives 
from 'binding.Component'.  'web.Resource' doesn't need dynamic 
configuration, but 'ResourceDirectory' objects are configured from 
'resource.ini' files, so they need to support dynamic configuration.  Thus, 
I changed the 'ResourceDirectory' definition from:

     class ResourceDirectory(Resource):
         ...

to:

     class ResourceDirectory(Resource,binding.Configurable):
         ...

This mixes in the necessary support for dynamic configuration, without 
forcing 'Resource' to also support dynamic configuration.

Anyway, the net result of this change is to *speed up* most configuration 
lookups, because of some eliminated calls and conditionals in 
binding.Component.  Even the new binding.Configurable runs faster than the 
old binding.Component did, because its execution path also eliminates extra 
calls and conditionals.