Am Dienstag 15 Dezember 2009 17:16:12 schrieb Thomas Lotze: > So we've decided to let interfaces grow `adapt` and `utility` methods. I've > written a simple and straight-forward implementation of them (see the > tlotze-component-API branches of zope.interface and zope.component) that is > closely modelled on the exisiting `__call__`. In particular, the new > methods use component hooks which are like adapter hooks but with a richer > set of call parameters. There are a few tests for the new methods as well, > so everything should be fine. > > Except that I don't like the implications now that I have actually written > down the code. I'll describe the problem I see and then suggest an idea > that I don't think we've been considering in the discussion two weeks ago: > > We're intentionally leaking the concept of utilities to zope.interface. > Assuming we're entirely fine with this, we still need to decide how much of > the particulars of the ZCA we want to bring along: named components, lookup > contexts, the ComponentLookupError. My current implementation tries to > introduce enough generic behaviour into the `adapt` and `utility` methods > so that they don't cause too obvious (conceptual) dependencies of > zope.interface on zope.component: > > * `adapt` and `utility` don't define particular optional arguments but pass > all keyword parameters except for `default` to the component hook which, > being implemented by zope.component, keeps the knowledge about named > adapters and lookup contexts within the latter package. > > * The hook invokes the `query*` functions to play nice with any other > component hooks and the interface methods raise a TypeError if all of > them fail to find a component. > > However, the generic behaviour gets in our way: the method signatures > become useless and hooks lose the possibility of raising useful > exceptions. > > I've tried some variations but as long as the `adapt` and `utility` methods > are actually implemented by zope.interface, it will always come down to a > compromise that either renders the new methods unusable with anything > that's not very much like zope.component, or makes for a half-hearted copy > of the functionality we currently have in the zope.component API. > > I discussed this a bit with Wolfgang as we both don't like this kind of > compromise in such core functionality. We came up with the idea that a > clean solution would be to keep any implementation of the two methods out > of zope.interface and rather inject them into the interface API by code > kept entirely within zope.component. We do realise how close to the > concept of monkey-patching this comes, but maybe it wouldn't be so bad if > we could do it in a more structured way (being intentionally vague here > yet). > > In particular, keeping the concrete `adapt` and `utility` methods out of > the core implementation of interfaces would address the concern raised by > somebody on this list that we were going to tailor zope.interface too much > to the needs of the Zope ecosystem. Uses of interfaces other than > adaptation and component lookup could get convenience methods registered > by the same mechanism zope.component would end up employing, which is a > big conceptual advantage from my point of view. > > What do people think of this? > Conceptually, this sounds a lot like what I was thinking when I read the discussion, a week or two ago. So I am very much like the idea - to let an interface be an interface without bringing it into tight coupling to other zope-concepts.
So the remaining question is, how to implement this in a clean way and still keeping the usage simple and readable. Something like IFoo.do.adapt(x,y) and IFoo.do.get_utility() (as well as IFoo.do.something_completely_different() ) would be possible, but somewhat unusual ... Mat _______________________________________________ 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 )