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

[Martin Aspeli]

Hi Chris,

>>> In repoze.bfg, we've actually decided to use a subclass of the component
>>> registry which also inherits from "dict".  This makes it possible to 
>>> spell
>>> common unnamed "utility" registrations and lookups as:
>>>
>>> utility = SomeUtilityImplementation()
>>> registry['someutility'] = utility


I rather like the simplicity of this, so in general +1, but let's hear 
Matt out too.

>> While I'm all for simplification, this makes very little sense to me.  
>> If this is an unnamed registration why is there a name ('someutility') 
>> involved?
>>
>> If it was a named registration against Interface, or if the key was an 
>> interface/dotted name that'd make sense.
> 
> You may have Zope Component Developer's Eyes, a common disease in these parts. ;-)

I know you were joking, but bear in mind that you're proposing a change 
to the most fundamental part of the Zope ecosystem, so that disease is 
not really a disease. :)

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.

> If you haven't already, you might take a look at the example after the 
> paragraph that starts with "But we recognize that developers who my want to 
> extend the framework..." within:
> 
> <http://docs.repoze.org/bfg/1.1/designdefense.html#ameliorations>

Nice write-up. :)

> In a system like this, there are no interfaces; the string 'root_factory' 
> performs the same job as the IRootFactory interface for registration and 
> lookup.  I'd like to make the ZCA registry operate like this.  There's really 
> no reason for there to be an interface hanging around to represent this thing: 
> we're using the ZCA as a complicated dictionary here.

I think there is a reason, though you may not agree it's a good one. The 
interface makes a promise about what the component is supposed to be 
able to do. We don't enforce that in our duck-typing programming 
language, but I think there is value in being able to say, "I want an 
object that conforms to this interface (i.e. delivers what the interface 
promises) - please get me the best one you've got".

> It would also obviously be possible to just add a dictionary instance attribute 
> to a registry, so instead of subclassing Components from dict, you might do:
> 
> reg = getSiteManager()
> reg.simple['root_factory'] = root_factory
> 
> To be honest, I don't mind one way or another; I'd just like to push whatever 
> we do upstream if possible.  If we move too far away from the stock ZCA 
> facilities, it becomes harder to integrate Zope apps into BFG and vice versa.

I whole-heartedly agree, and I think it's important that we use the 
momentum behind BFG (and other consumers of the ZTK) to drive the ZTK 
forward. Anything else would be stupid.

I'm still concerned that your proposal basically leaves us with two ways 
of implementing the singleton pattern with the ZCA, and I'm not sure 
that's in our best interest. I'd be interested to hear your thoughts 
further, though.

Off the top of my head, another way to think of this *might* be to say 
that the 'dict access' is basically looking up a *named* utility 
providing a very generic marker interface, e.g. 
zope.component.interfaces.IUtility or even just 
zope.interface.Interface. That way reg['foo'] == getUtility(IUtility, 
name='foo'). Obviously, assignment would register in the same way.

I'm not sure it's "better", though. :)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book