[Zope-dev] A summary of "Interfaces vs ZCA concepts"

[Thomas Lotze]

Martijn Faassen wrote:

> Here's a summary of what has been going on in this thread with some
> attempts at conclusions that have support of the consensus so that Thomas
> can proceed

Thank you, half an hour later and I'd have written the summary ;o)

> * We want to implement .adapter(), .utility() and .__call__() in
> zope.component as much as possible.

The method's name is `adapt`, JFTR.

> * we want a similar mechanism for each of them to plug in.

Agreed, even though (AFAICT) we haven't been talking about moving the
implementation of __call__ to zope.component so far.

> * It'd be nice if __call__ came back with a LookupError instead of a
> TypeError, but how to get from A to B without breakage?

It's not possible without breakage. I'd say changing the error is worth a
4.0 release, but we might want to postpone this change and see whether
there's anything else we want to change about zope.interface in a
backwards-incompatible way, and if so, put that in the 4.0 release as
well. I guess we don't want too many backwards-incompatible releases of
such a central package.

One thing I start questioning is an adapter registry being implemented by
zope.interface. Moving it to zope.component seems to me to be related to
keeping the implementations of the new method within zope.component.

> * there was some discussion about general plugin points on Interface.
> Those have a complexity cost compared to simply poking the methods into
> the class.

As for poking the methods into the class, see the new
tlotze-patching-interfaces branches of zope.interface and zope.component
for the minimum change this would take IMO. The change to zope.interface
is really just about documentation.

> * the methods can be on zope.interface even if zope.component isn't
> installed. They will behave as if the component registry is empty.

This isn't covered by the consensus you mentioned above as far as I'm
concerned.

> Their behavior should be:
> 
> IFoo.adapt(context) raises LookupError, unless the context provides IFoo,
> in which case it returns context.
> 
> IFoo.adapt(context, default=default) returns default unless context
> provides IFoo, in which case it returns context.
> 
> IFoo.utility() raises LookupError.
> 
> IFoo.utility(default=default) returns default

I think looking at that API explains why we have trouble with having stub
methods defined by zope.interface: these methods contain enough
information about component concepts to blur the distinction between
zope.interface and zope.component, but they still lie about the actual
method signature. In that sense, these stubs would be worse than
zope.interface not documenting the methods at all.

In my and Wolfgang's opinion, we can either have zope.interface implement
methods with the real contract, which would mean defining the full
concepts of the ZCA within zope.interface (if not their implementation),
or not even have method stubs in zope.interface and leave the whole
business of defining specialised uses of interfaces to other packages such
as zope.component.

> What's the behavior of __call__ now if zope.component isn't around?

Similar to what you've just described of your `adapt` method, up to the
name of the `default` parameter and the exception raised.

> * Tres brought up that we can come up with a clean plugin interface
> instead, and now I'm tempted to go for that instead of monkey-ing around.
[...]

I'd have to think about that some more, but while reading it the first
time, it feels quite wrong to me.

> I realize that the proposal for a plugin API gives zope.interface some
> knowledge about adaption and utility lookups, which is what Thomas and
> Wolfgang had trouble with. But after all that's what we're doing anyway by
> putting those methods on the API, one way or another.

No: the zope.interface package doesn't have any knowledge about the
particulars of any of the uses of interfaces. One might claim that
interfaces do after they've been patched by other code, but then, that's
after some application has made its choice about plugin certain packages
together. It's not baked into zope.interface, and that's what we're trying
so hard to achieve.

> [Philosophically from my own perspective I think we'd have much less
> conceptual difficulty with this if we just made __call__ do all lookups,
> as that hides the whole set of concepts of utility versus adapter a bit,
> but we can't get consensus for that unfortunately. But I'm biding my
> time..]

Implementing __call__ within zope.interface in that way would get the
package rid of the method names `adapt` and `utility`, but the technical
problem with the method signatures and the more philosophical one about
whether zope.interface should really make adaptation stand out as a use of
interfaces remains.

Which brings me back to the question I asked earlier, and which nobody has
replied to so far: Do we want to make zope.interface completely unaware of
any particular uses of interfaces, or do we want to treat component lookup
and in particular the ZCA's way of looking up components as a special case?

-- 
Thomas