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
>  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.
> Thoughts?

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.

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to