[Zope-dev] Interfaces vs ZCA concepts

[Martijn Faassen]

Hey,

Good to see there's progress!

Thomas Lotze wrote:
[snip]
> 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.

A TypeError instead of a ComponentLookupError?

I was thinking we should keep the behavior as close to zope.component as 
we can, including ComponentLookupError. Don't you get a 
ComponentLookupError with the classic adapter hook too? So I'm -1 to 
making this a TypeError.

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

I think a monkey patch would be fine. Opinions about making it more 
structured:

* have dummy implementations in zope.interface that raise 
NotImplementedError

* have that NotImplementedError say to look for implementations in 
zope.component

* have the docstring of these methods also talk about zope.component

* have the docstring on the methods that are injected be clear that they 
are being injected into zope.interface

That way someone reading the zope.interface code can at least find out 
that this functionality is injected from zope.component.

[as an aside it'd be interesting to find out how much of of 
zope.component functionality could sensibly make it into zope.interface, 
but that's another project; Gary Poster has some ideas in relation to this]

> 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?

I'm +1 on this general approach. Implementation in zope.component, and 
inject it into zope.interface during import time.

I'm still sneakily hoping that in a few years we'll be able to get 
calling the interface be the one true way of looking up implementations 
of that interface (utilities and adapters and whatnots), but we'll see.

Did you make an implicit 'default' deprecated on __call__ yet by the way?

Regards,

Martijn