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.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
First cuts of this at:
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -