Re: make zope.component.registry.Components inherit from dict?

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

_______________________________________________
Zope-Dev maillist  -  [email protected]
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 )