Re: make zope.component.registry.Components inherit from dict?
Chris McDonough <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )