Re: split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs)
Gary Poster <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Message-ID | <[email protected]> |
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. Gary _______________________________________________ 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 )