* Chris McDonough <chr...@plope.com> [2011-08-26 13:27]:
> > So I'd like to propose to do the split the other way around: Not
> > extract the core into something else and leave only a hollowed-out
> > shell of integration and miscellany stuff behind, but rather tighten
> > zope.component to its core and move the optional integration bits out
> > of it, into separate packages.
> I'm -1 on redefining the meaning of zope.component.

I'm afraid I don't understand what you're saying. Could you expand on
this? What meaning is redefined to what by which proposed action(s)?

> Otoh, if the name "zope.registry" (or the introduction of a new
> package) is a problem, I'd suggest we move the stuff that is
> currently in "zope.registry" to zope.interface. zope.interface
> already contains a bunch of registry-related code; it'd make
> complete sense to me.

That's an interesting suggestion, since zope.interface contains the
bigger half of all the adapter mechanics already. (zope.interface
would gain the concept "utility", an adapter "from" nothing, but I
wouldn't mind that, I guess.)

However, my main driving point here is coherent package boundaries,
and as said elsewhere in this thread, I think that the core of
zope.component comprises more than just the Registry class, namely the
(hookable) getSiteManager protocol and probably zope.event integration
-- and I'm not sure that all this belongs into zope.interface.


Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
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