Chris McDonough wrote:
Except at this point we've lost all the other ZCA stuff. You can't override with a local utility, for example.
I see. I didn't understand that this was a use case, because I don't use any persistent registries. If you say this is a use case, I believe it.
Note that you can also have "local" registries that are not persistent. It's just a chain of lookups, where each registry knows its bases. Some unholy code in KSS turns a view into a component site, I think. But let's not go there.
Sure, I could have another dictionary laying around as a thread local. I already effectively do that now; the particular thread local dictionary I use just happens to *be* the registry. Libraries written that make use of that feature in BFG are not usable within Zope, however, which is suboptimal.
I agree. However, if we're starting down the path of making a totally different registry keyed in a totally different way, I wonder why we're even thinking of doing this with the concept of the ZCA at all. I *do* actually like the "named IAnonymousUtility" thing as a convenience, because it retains some consistency. Maybe it's slower, which would be a negative. But it also allows all the other ZCA stuff (overriding, introspection, global/local variants, etc) and API: we're just introducing a convenience. Conversely, *if* we're not using any other "ZCA stuff", then it probably belongs elsewhere.
The types of data contained by both the dictionary I want and the ZCA are the same types of things (statements about application configuration, expressed conceptually as "utilities"). We only need one thread local to hold application configuration; having N of them is an anti-use-case, and having multiple of them implies balkanization.
This I agree with, but in effect, if we have a self.utils = {} in __init__, then we actually have two registries that have nothing to do with each other. :)
So if you say that you must be able to override registrations made via "reg['foo']" or "reg.utils['foo']" with a local utility via "localreg.registerUtility(someoverride, IAnonymousUtility, name='foo')", and that the local utility registry can't handle "localreg['foo']" sensibly by falling back to "globalreg['foo']", I'd believe you, even though I don't understand why not. It's not that important, really.
Sure, we could implement the same type of fallback in __getitem__ or whatever. But now we're building the same thing twice, are we not?
Maybe it's better to look into the stacked variables that Pylons uses for some of its configuration stuff?
Hell no. That particular implementation is a holy mess.
Well, I didn't know that. ;-) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book