[Zope-dev] make zope.component.registry.Components inherit from dict?

[Chris McDonough]

Martin Aspeli wrote:
> Chris McDonough wrote:
> 
>> I think we have to divorce the requirement from "the ZCA".
>>
>> The requirement:
>>
>> - an attribute of an instance of the class
>>    "zope.component.registry.Components" which is dictionarylike
>>    (accepts any key type, any value type).
>>
>> If I can get that, I'd be happy, regardless of what's happening under the hood. 
>>     If you want to turn this into a component lookup, that'd be fine; if not, 
>> that'd be fine too.
>>
>> That said, if I had just added a separate attribute ithat is a dict inside the 
>> Components constructor (instead of subclassing Components from dict) and 
>> checked it in, would anyone have cared? This isn't a feature that any Zope 
>> developer really *has* to use, it's just a feature that provides compatibility 
>> between future BFG apps and Zope.  It'd also be possible to change its 
>> implementation in the future if we thought it should use utility registrations.
> 
> ...
> 
>> We already have this situation.  The Components class is already a wrapper that 
>> has an "adapters" attribute (an instance of a zope.interface AdapterRegistry) 
>> and a  "utilities" attribute (an instance of something else).  All adapter and 
>> utility state is kept in these substructures.
>>
>> While maybe it would be wrong to refer to the things manipulated via a dictlike 
>> object as an additional attribute of the class as "utilities", adding another 
>> attribute and exposing a wrapper API is a pattern that is already embraced by 
>> the class.
> 
> If it were just another attribute analogous to .utilities and .adapters, 
> calling it "utils" or "utilities" would be misleading, because it's not 
> actually a utility. You could call it "settings" or something.
> 
> However, you'd still need to implement support for __bases__ and all 
> that: getSiteManager() will return the nearest site manager, so if it 
> was just a "dumb" dictionary you'd get a KeyError as soon as you'd 
> traversed over a site (e.g. into a Plone site), thus setting a local 
> site manager. You *could* use getGlobalSiteManager() every time, but 
> then people have to know that .settings is only on the global site manager.
> 
> And you'd still have to do all the wiring in Python, or invent a new 
> ZCML directive. Wiring at module import time is not ideal.
> 
> Conversely, if you implement it so that it's backed by named utilities 
> providing Interface, then it's just a convenience and we still have the 
> same override and introspection mechanisms we've always had for 
> utilities. That sounds like a good bit of "internal consistency" to me.

I fear it was for naught, sorry.

Adding an attribute is unsightly and turning this into a component problem 
doesn't have enough immediate gain.  The BFG registry will just continue to be 
a dict subclass.

If Zope folks later want to use libraries that come from BFG-land (particularly 
libraries that have ZCML directives), they'll just need to deal with code that 
wants to use the dict API against the component registry.

- C