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