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

[Wolfgang Schnerring]

* Martijn Faassen <faassen at startifact.com> [2009-12-17 17:48]:
> * Thomas Lotze <tl at gocept.com>:
> > zope.interface [should be] completely unaware of any particular uses
> > of interfaces
>
> Why is it a problem that the zope.interface package gains knowledge 
> about adaptation (which it always had, anyway) and utility lookup? 

This is the key issue, I think.
(And I'd like to ask you not to argue "it has always been that way",
since what we're trying to do here precisely is to improve the status
quo.)

The question is, which concepts belong into zope.interface and which don't?
One might also phrase that as, what is the responsibility and purpose of
zope.interface (drawing upon the software engineering terms of cohesion
and coupling).

My opinion is that

> [__call__ introduces] the following notion into zope.interface:
> "please look up an object that provides this interface, somehow. (with 
> zero or more context objects)"

might well belong into zope.interface, but that anything of these:

> adapters, utilities, null-adapters or contextual utilities

absolutely do not.

I think there is a clear distinction between what "interfaces" are about
and what "component architecture" is about, and I think it is worthwile
to maintain and clarify that distinction.

For me, a notion of "looking up something that provides an interface"
belongs to what "interfaces" are about.
But notions of "utilities" which might or might not be singletons, of
"adapters" which might or might not take additional parameters such as a
name to look them up, or notions of a "context" or a "registry" (which
for me comes up immediately when thinking about "global" vs. "local"
utilities) that influences the lookup, for me emphatically do *not* belong
to what "interfaces" are about.

By putting method stubs into zope.interface which are exclusively about
concepts of zope.component we would be
a) On a conceptual level: blurring the distinction between the two
packages and concepts, which I think is a Bad Thing(tm)
b) On a more practical level: coupling zope.interface to zope.component.
Given all the recent efforts of untangling the dependency structure
between our packages, I think doing that would be a step in the exact
opposite direction.

Wolfgang