[Zope-dev] split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs)

[Martijn Faassen]

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
>    security.
> 
> - 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.

One of my first responses would be some worry about zope.component 
growing a *new* dependency. The goal of zope.component is that it's one 
of those packages with only a few...

I'm trying to see who would be using zope.registry for what exactly. 
Would it be much harder to experiment with these new APIs on top of 
zope.component? You'll get a bit more baggage, but the minimal 
dependency story should be quite small already. I'd rather get some of 
the additional dependencies (that have a lot to do with supporting ZCML) 
out of it, instead of moving its core functionality out.

You factored various related things together - perhaps it would make 
sense to do this refactoring within zope.component?

I'm +1 on making zope.event part of zope.component and deprecating 
zope.event.

Speculating, would it instead make sense to move zope.registry 
functionality into zope.interface? The only additional dependency is 
zope.event. At first glance the answer would be "no" as it really 
introduces various component architecture concepts...

Regards,

Martijn