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

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  -  [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 )