[Zope-dev] make zope.component.registry.Components inherit from dict?
optilude+lists at gmail.com
Tue Nov 24 00:31:51 EST 2009
Chris McDonough wrote:
>> A lookup keyed entirely on strings and not interfaces is perfectly
>> possible using the ZCA, just register your utility to provide
>> z.i.Interface and name it. Your semantics are the same as the simple
>> dictionary use-case, but it doesn't force people to choose one means of
>> access over another.
> I don't think I understand. Could you provide an example?
See my post - I think Matt and I had the same thought.
> I don't really have enough context to understand how it would be confusing, but
> I trust that it would. Persistent registries are traversable?
The ++etc++site namespace shows you persistent components. You can
delete them in the ZMI to remove registrations, and, in some Zope 3
apps, add them via an add menu, even.
In Zope 2, there's been some mixing of OFS.Folder with component
registries, and OFS.Folder uses some dict API. However, I think it'd be
OK to "break" that and use a more bespoke screen to be honest.
> In practice, I don't actually find it very useful to register somthing that you
> know will be a singleton as a literal ZCA utility, anyway, because there's
> exactly one lookup pattern: set it, get it. I don't think I've ever performed
> an unnamed utility lookup expecting that a "more specific" implementation of a
> utility might be returned because I've passed some subtype of a more general
> interface. How about you?
No, but I have expected a local registry to be able to override, which
is an important use case.
> Ok, so be it, we will diverge. Shame, that, because it will mean that software
> libraries composed expecting the r.bfg registry may not work under Zope,
> further fracturing things.
Let's not give up just yet. I think there's a lot of value in
convergence here, so we should be able to find an approach that will.
And Matt and I aren't the only voices to be heard.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Zope-Dev