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

[Martin Aspeli]

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.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book