[Zope-dev] Interfaces vs ZCA concepts

[Matthias Lehmann]

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