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

[Martijn Faassen]

Wolfgang Schnerring wrote:
> * 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.)

I'm saying that because I don't recall people arguing against this 
before. Since the __call__ logic is only about adapter lookup, does this 
mean that your argument is expanded against this as well or does it fall 
under the notion of looking up anything by interface? I think from the 
rest of your mail that you mean the latter. At least it's a strict 
subset of an expanded notion of "lookup".

[snip]
> By putting method stubs into zope.interface which are exclusively about
> concepts of zope.component we would be

I would say that to be consistent in that position, you would need to 
argue not just against method stubs but against the presence of these 
methods at all, no matter where they come from. The rest is just an 
implementation detail.

Reasoning from your position that zope.interface shouldn't have notions 
of adapter and utility lookup, it hardly matters what package implements 
these methods. To the user of Interface it will look the same, except 
that zope.component monkey-patching things in would be harder to 
understand and debug.

To be consistent we have the following options:

* only provide a general notion of "looking up something by interface" 
in zope.interface. This general notion unfortunately clearly doesn't 
have support from a large number of people so sadly I had to let that go.

* not change anything at all. Looking up these things remains the task 
of zope.component and we better use zope.component APIs.

Monkey-patching methods in from another package to me looks like it 
doesn't improve the conceptual story at all. Conceptually Interface ends 
up as messed up as before and it becomes more difficult to understand 
what's going on for the code reader or debugger.

 > which might or might not take additional parameters such as a
 > name to look them up ...
 > for me emphatically do *not* belong to what "interfaces" are about.

I think you can see a name as another context in a multi-adaptation, 
where this context is special in that:

* it needs to be human-readable text

* it cannot extend another name, unlike interfaces, which can extend 
each other

It's just a handy shortcut. :)

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

I don't think the dependency refactoring argument holds. We were 
untangling physical dependencies. This wouldn't change physical 
dependencies one bit: zope.component would still depend on 
zope.interface. There are likely tons of places where package A depends 
on package B and also configures package B, changing its behavior. This 
would be no different: zope.component depends on zope.interface and 
plugs into it as well to configure some of its behavior. That's what it 
does today with the adapter hook.

Putting notions of conceptual purity aside, I was arguing for a 
pragmatic solution that results in code that is as unsurprising as possible.

I don't think .adapt and .utility are perfect, and I would have gone for 
another solution myself (a more generalized lookup method), but they 
seem to have consensus support. I don't think they do much in the way of 
active harm by being there in zope.interface. They help readability of 
the code that uses them. Moreover, this pragmatic solution would make 
code that looks up multi adapters and utilities more convenient to write.

So, zope.interface needs to gain these methods, and open up a plugin 
point so that these methods can be fully implemented by another package. 
I think this can be constructed so that the only new notions to 
zope.interface are:

* multi-adaptation, an extension of adaptation

* look up by name, a conceptual extension of multi-adaptation :)

* utility lookup

Too many for my tastes when there's such an elegant general lookup 
method available, but I can't convince enough people of that.

If we are going to make Interface support these methods for pragmatic 
considerations, we should just face it and implement them on Interface 
(delegating to a plugin). Anything else just helps to obfuscate what is 
going on.

Regards,

Martijn