Martin Aspeli wrote: > 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.
OK. >> 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. I think we have to divorce the requirement from "the ZCA". The requirement: - an attribute of an instance of the class "zope.component.registry.Components" which is dictionarylike (accepts any key type, any value type). If I can get that, I'd be happy, regardless of what's happening under the hood. If you want to turn this into a component lookup, that'd be fine; if not, that'd be fine too. That said, if I had just added a separate attribute ithat is a dict inside the Components constructor (instead of subclassing Components from dict) and checked it in, would anyone have cared? This isn't a feature that any Zope developer really *has* to use, it's just a feature that provides compatibility between future BFG apps and Zope. It'd also be possible to change its implementation in the future if we thought it should use utility registrations. > 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. :) We already have this situation. The Components class is already a wrapper that has an "adapters" attribute (an instance of a zope.interface AdapterRegistry) and a "utilities" attribute (an instance of something else). All adapter and utility state is kept in these substructures. While maybe it would be wrong to refer to the things manipulated via a dictlike object as an additional attribute of the class as "utilities", adding another attribute and exposing a wrapper API is a pattern that is already embraced by the class. >> 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? If it didn't exist, what's the worst thing that could happen? - C _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )