* Chris McDonough <chrism@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 -- Wolfgang Schnerring · ws@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