Martin Aspeli wrote:
> Chris McDonough wrote:
> 
>> I fear it was for naught, sorry.
>>
>> Adding an attribute is unsightly and turning this into a component problem 
>> doesn't have enough immediate gain.  The BFG registry will just continue to 
>> be 
>> a dict subclass.
>>
>> If Zope folks later want to use libraries that come from BFG-land 
>> (particularly 
>> libraries that have ZCML directives), they'll just need to deal with code 
>> that 
>> wants to use the dict API against the component registry.
> 
> If you're going down this route, my suggestion would be to not (ab)use 
> the ZCA site manager object for this at all. I'd have it be something 
> separate you access via a getConfigRegistry() or whatever. Threadlocals 
> are easy enough to set up.

Any app using more than one thread local for objects that have the same "scope" 
tends to make for a pretty rotten testing experience (see Pylons).  We already 
have the right number of objects to hold app config: one; it's the ZCA 
registry.  Making the registry into a dict is the simplest solution to the 
problem defined in the "defending design" document.

If some BFG-centric library becomes a runaway success, and some Zope user wants 
to use it in Zope, Zope will need to deal with it, or he will need to change 
the library to not use the feature.  That's fine.

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

Reply via email to