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