[Zope-dev] Interfaces vs ZCA concepts

[Thomas Lotze]

Martijn Faassen wrote:

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

The ComponentLookupError is defined by zope.component. So the only way of
getting a CLE raised by Interface.adapt or Interface.utility would be to
call the non-query-style lookup functions from the zope.component API and
let the error propagate. The current implementation of the new interface
methods pretend, however, to allow for more hookability than just calling
a zope.component function, so it is intentional to not let any error
propagate but defer to the next hook instead and raise an exception of a
type known to zope.interface (i.e. not CLE) if none of the hooks succeeds.

The choice of TypeError was made in analogy with __call__. Currently, you
get a TypeError if IFoo(bar) fails while
zope.component.getAdapter(bar, IFoo) raises CLE.

IMO, the clean way to solve this is to drop the analogy with the __call__
implementation and no longer try to cater for generic `adapt` and
`utility` behaviour. Together with avoiding a direct dependency of
zope.interface on zope.component, this leads to injecting non-hookable
implementations of `adapt` and `utility` from zope.component itself.

> I think a monkey patch would be fine. Opinions about making it more
> structured:
> 
> * have dummy implementations in zope.interface that raise
> NotImplementedError

That would still introduce too many zope.component concepts into
zope.interface IMO: obviously that of utilities as one of the dummy
methods would bear that name, and those of named components and lookup
contexts if the methods were to be specified by IInterface.

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

I would actually like a mechanism that doesn't care about what package
will inject which pieces of API. Do you think such generality is asking
too much (at least at this point in time)?

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

Of course.

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

IMO, we should mention this as a usage example but not as a requirement.

> [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]

I think before doing such a thing, we should come up with a precise
definition of which concepts are the concern of interfaces, which are that
of the ZCA and exactly where to draw the line. Anything else looks IMO
dangerously like a slippery slope towards mixing it all up into
zope.interface.

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

Me too.

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

Not yet; the other issue looked more interesting so far ;o) BTW, that
parameter isn't even called 'default' but 'alternate' in
Interface.__call__. The very name of the default argument is another thing
that is sneaking from zope.component into zope.component.

-- 
Thomas