[Zope-dev] split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs)
gary.poster at gmail.com
Wed Nov 25 17:36:44 EST 2009
On Nov 25, 2009, at 5:08 PM, Chris McDonough wrote:
> Chris McDonough wrote:
>>> If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing).
> The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module.
> It would be useful to split these core mechanics into a separate package. Here's why:
> - The zope.component module carries along an expectation of a particular global
> API. This global API is not required to use the mechanics of the underlying
> registry machinery.
> - The zope.component package has a number of features that are irrelevant
> to the operation of the core registry itself, such as persistence and
> - The registry itself is useful outside the context of the zope.component API
> package; the API is essentially just "candy" on top of the registry itself.
> I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry
> It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency).
> After that's done, I'd suggest we make zope.component depend on zope.registry.
> At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app.
FWIW, it's not of a lot of interest to me. I'm interested in changing things at a lower level. However that works, if I manage to build zope.component backwards compatibility as an add-on then I'll have to worry about all of the bits in zope.component, not just this.
More information about the Zope-Dev