On Thu, 2011-09-08 at 19:03 -0400, Chris McDonough wrote: > On Thu, 2011-09-08 at 13:39 +0200, Wolfgang Schnerring wrote: > > * Chris McDonough <chr...@plope.com> [2011-09-08 05:21]: > > > On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote: > > > > Yes, I like the idea of a "fresh start" (or at least "proper clean > > > > up") quite a bit. And I'd definitely be up for writing (new) > > > > documentation. You've set a great example in that regard with Pyramid > > > > that is very much worth emulating for other packages. > > > > > > I'm behind the goal of cleaning up and documenting componenty things > > > better, and I think those are very worthy ideas. But I think blocking > > > the proposed division while we hash out the details of what some second > > > generation zope.component might be is probably not in anyone's best > > > interest. If there were some branch laying around with a proposed set > > > of changes, it might be more reasonable, but there's not, and it will > > > take months to create one (after discussion, planning, development, > > > rehashing, etc). The creation of a second package today that just holds > > > the proposed bits doesn't prevent future innovation, AFAICT. > > > > I guess that extracting just a little bit right now won't get in the > > way of "doing things properly" (since that most likely means > > extracting a little more and then documenting it), and I certainly > > don't want to stand in the way there. > > > > However, that means that the package currently called "zope.registry" > > will quite likely become the "future" of zope.component. In that light > > I'd really like to try and come up with a better name -- Jim? > > I mentioned previously that it's not that much of a stretch to put this > code into zope.interface because zope.interface.adapter already defines > registry-ish stuff that possesses most of the same concepts as a > component registry. It has a class named "AdapterRegistry" already that > has a very similar API as a full-on component registry. The full-on > component registry really just an API implemented in terms of multiple > z.i.adapter.AdapterRegistry instances. > > With that in mind, and in the interest of moving forward, I'd suggest we > just ditch the zope.registry package and move its code into > zope.interface. Then there's no renaming to do at all, we can still > innovate in the future without necessarily decommissioning a package. > As a bonus, we'll have one fewer dependency package. > > The zope.registry registration machinery sends events when its API is > called. It'd be a bit sucky to have z.event as a hard dependency of > zope.interface. But it'd be dead easy to change it to only send > registration events if zope.event could be imported. I doubt there's > anything listening for these events that doesn't also already depend on > zope.event. > > zope.registry also currently provides a minor API in the way of an > "adapts" decorator. This could (and should) be moved back into > zope.component; it's actually not used internally by zope.registry now > (although some decoy imports would make you think so if you look at > zope.registry.__init__).
First cuts of this at: http://svn.zope.org/zope.component/branches/chrism-zope.interface-componentregistry/ http://svn.zope.org/zope.interface/branches/chrism-componentregistry/ - C _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
