[Zope-dev] make zope.component.registry.Components inherit from dict?

[Martin Aspeli]

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.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book