[Zope-dev] make zope.component.registry.Components inherit from dict?

[Chris McDonough]

Martin Aspeli wrote:
> Hi Chris,
> 
> Chris McDonough wrote:
>> Martin Aspeli wrote:
>>> We need to make sure that we're not inventing a different way to achieve 
>>> something which is already possible. This will lead to confusion, 
>>> because people will have to know "which way" is applicable in a given 
>>> situation, and the distinction will seem arbitrary.
>> I fear we are indeed inventing a different way to achieve something which is 
>> already possible.  We aren't doing it arbitrarily, though: the current way just 
>> requires the use of an interface instead of a string.  Interface usage for such 
>> a simple pattern implies a cognitive load that appears to exceed the pain point 
>> of most Python developers who are not already familiar with Zope.  So we'd like 
>> to ameliorate that as best we can.
> 
> I wish I knew what "ameliorate" meant, but I'm sure I agree.

Ha, sorry, I've been writing documentation and trying to sound smart.  "fix". ;-)

> My concern is that we also have a pretty large existing user base to 
> worry about, and we wouldn't want to confuse them. Or, indeed, new users 
> confronted with code that has been written up to this point.

Right.

I don't think there's any way we could further confuse existing users: there 
aren't really any existing docs for the``zope.component.registry.Component`` 
object which would reinforce a set of expectations that would exclude use of a 
dict API against it.  As far as I can tell, existing user-consumable 
documentation documents the threadlocal API only.  (I am beginning to think the 
broadness of the threadlocal API is itself a problem, but that's another issue 
entirely.)

New users confronted with old code: well, we already have this problem, and at 
least if we make incremental improvements like this one, we have a shot at 
making existing code more readable.

> I think it would be nicer, because we could tell a story like this:
> 
>   - if you just want a place to store things by name...
>   - ... which can be overridden at runtime or customised with local 
> components ...
>   - ... and you don't care too much about the notion of an interface ...
>   - ... then here's the ZCA way to look up a component by name only
> 
> To register:
> 
>    reg = getSiteManager()
>    reg['rootfactory'] = MyRoot()
> 
> To retrieve:
> 
>    reg['rootfactory']
> 
> To delete:
> 
>    del reg['rootfactory']
> 
> 
> The equivalent ideas would be:
> 
>    reg.registerUtility(MyRoot(), provides=Interface, name='rootfactory')
>    getUtility(Interface, name='rootfactory')
>    reg.unregisterUtility(provides=Interface, name='rootfactory')
> 
> Although I suspect we want a marker interface that's a bit more specific 
> than just 'Interface' since we already have some things that register 
> interfaces as utility, I think. So maybe:
> 
>    class IAnonymousUtility(Interface):
>        pass

Yup, +1 on all that if it would mean the registry object got a complete dict 
API (although I think we'll need to fix the "name must be a string" issue I 
sent earlier).

To be honest, I'm not really sure that this pattern has much practical benefit 
over inheriting from dict, because it just means more (missing ;-) ) 
documentation, but I recognize the desire for "internal consistency".

- C