[Zope-dev] make zope.component.registry.Components inherit from dict?
optilude+lists at gmail.com
Mon Nov 23 23:57:50 EST 2009
>>> 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
>>> 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')
>> 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:
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
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. :)
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Zope-Dev