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

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.


- C

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to