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

[Martijn Faassen]

Hey,

A few points instead of a point by point reply.

* I thought we had agreed to add methods to Interface that support multi 
adapter and utility lookup. We seem to have, but only about the external 
API, not about where the implementation is. (even if in my plugin 
proposal the implementation still lies in zope.component)

* Apparently not even single adapter lookup is supported by you, at 
least as implemented in zope.interface. I had not previously realized 
that the current implementation of __call__ could be considered wrong by 
you.

* You appear to be looking for something that at least in the Python 
language is only accepted as a kind of hack: an ability to extend the 
API of an existing class far away from the definition of that class, 
without there being a subclassing relationship (or I suppose, a class 
decorator). The idea in Python is generally that the API of a class is 
defined by that class or its base classes, not elsewhere.

* There is of course a way to extend what one can do with an object in 
Python. Subclassing is one way, adaptation another, and defining 
functions another. The last is what zope.component does.

* I do not know of a user community that uses zope.interface and does 
not use a component architecture. The Twisted community for instance 
uses zope.interface's adapter registry and __call__ hook. This is an 
argument for making component lookup an integral part of 
zope.interface's responsibilities. I think you could even make an 
argument for folding zope.component's responsibilities into 
zope.interface, though I'm not currently proposing this (also because 
we're are looking to improve the implementation, see below). 
Generalizing what kinds of component lookups one can do using Interface 
seems like a good idea from this perspective.

* I think it is entirely possible that people will plug in alternative 
component lookup strategies to zope.interface in the future, as the long 
discussion also involved changing the way zope.component's internals worked.

* All this questioning of fundamentals makes me inclined to give up on 
this project for the time being. I thought we had reached a conclusion, 
but I was wrong. Too many cooks?

Some more technical points:

* you wonder about a 'context' parameter. Are you talking about the 
lookup context here? We hadn't considered passing through the lookup 
context in previous discussions. We could leave that out for the time being.

* A single plugin seems fine instead of a list of plugin points for 
zope.interface. I think a single plugin, using a global would be the 
most straightforward and readable solution, but perhaps some performance 
measurements would be interesting.

Regards,

Martijn