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