[Zope3-dev] N-Tuple Adapters

[Shane Hathaway]

I've been pondering the idea of "n-tuple adapters".  The idea is that 
some adapters require multiple independent inputs.  Steve came up with 
the good name.

The need for n-tuple adapters arose when we implemented traversal 
components.  Traversal components determine how Zope traverses a path 
element in an URL or TALES expression.  We realized that a traversal 
component should expect two inputs, the object to traverse and the 
user-initiated request.  This requirement didn't fit the adapter 
pattern, since adapters can accept only one input.  So we decided to 
register traversal components as views with a special name, "_traverse".

But this solution was a hack.  A traversal component is not really a 
view at all.  It doesn't present anything to the user.  Conceptually, a 
traversal component is an adapter, since it adapts objects to traversal. 
  However, you may want a different traversal component for each 
protocol, or you may want only one traversal component for a certain 
class of protocols.

So a traversal component is really a two-tuple adapter.  Zope 3's 
current notion of adapters might be considered one-tuple adapters. 
Remember utilities?  We haven't used them much, but utilities could be 
zero-tuple adapters.  If we had an n-tuple adapter registry, we might 
use it to implement the view registry, since a view registry might be 
best implemented as a mapping from view name to two-tuple registry.

Would three-tuple and four-tuple adapters be useful?  Well, in thinking 
about all of this, I realized that n-tuple adapters are generic problem 
solvers.  When querying the adapter registry, the application provides 
inputs and asks for a component that can solve some problem using those 
inputs.  An n-tuple adapter registry is the digital version of 
MacGuyver: you have a chess board, a clothesline, a match, and shoes. 
How are you going to start that car? ;-)  Adapters, especially adapters 
that accept multiple inputs, add a limited form of problem-solving 
intelligence to the system.

With n-tuple adapter registries, we might begin to solve a whole new 
class of problems.  There could be numerous applications not only for 
Zope, but computing in general.

There's just one snag: how would we search for n-tuple adapters in a 
scaleable way, taking interface hierarchy into account?  A naive 
implementation would perform a multi-dimensional search, where the 
number of dimensions corresponds with the number of items in the input 
tuple.  To find an adapter that accepts (IFooFolder, IHTTPRequest), we 
have to search for a registered adapter that requires a set of 
interfaces, in the following order:

1. (IFooFolder, IHTTPRequest)
2. (IFolder, IHTTPRequest)
3. (IFooFolder, IRequest)
4. (IFolder, IRequest)

The search is ordered from most specific to most general because we have 
to find the most specific adapter available.  To complicate matters, we 
might prefer to reverse the order of #2 and #3, which is just as 
sensible.  And this example uses a shallow interface hierarchy.  A 
deeper hierarchy would require exponentially larger searches.

I've been thinking about ways to deal with this, but I'd like some input 
on the general idea first.  Do you think n-tuple adapters would be 
generally useful?  Is there a way to think about them that would reduce 
or eliminate the deep search?  Is there any research on this topic or 
something similar?

(BTW, this is just a foray into science fiction.  Don't implement 
anything yet, folks. ;-) )

Shane