[Zope3-dev] N-Tuple Adapters

[Shane Hathaway]

On Mon, 2 Jun 2003, Phillip J. Eby wrote:

> At 05:42 PM 6/2/03 -0400, Shane Hathaway wrote:
> >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.
> 
> May I suggest "multiple dispatch", since that's a more well-known term in 
> the literature?  Also, searching Google for "Python multiple dispatch" will 
> find you implementations you can play with, while searching for "n-tuple 
> adapters" won't.  :)  ("multimethod" is another good search term.)

Funny... I read the Mertz article just recently.  He jumped immediately
into implementation and failed to adequately describe what we was trying
to achieve, so I didn't understand.  Now I get it, thanks. ;-)

> >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.
> 
> This is actually a very old, and, generally speaking, very solved 
> problem.  See Lisp's CLOS, the Dylan language, and there's even a language 
> (Cecil I believe) that generalizes to "predicate dispatch" (selection of 
> code based on arbitrary query expressions, not just type).

That's the right term, I think.

> For your example with interfaces, each "feature" would be something like 
> "the object in position 1 implements IFooFolder".  We might represent that 
> as a tuple '(1,IFooFolder)'.  Predicates 1 and 3 in your list would be 
> listed under that feature.  The dispatcher would also need to be equipped 
> with a way to extract the features from an input query.  In your interface 
> example, this would mean generating '(i,iface)' pairs for all positions 'i' 
> and all implemented interfaces 'iface'.  For each position 'i', we union 
> the set of predicates that are registered for the implemented 
> interfaces.  Then, we intersect the sets of predicates for each position, 
> resulting in a set of candidate predicates which can then be sorted.

Yes, that's where my thoughts landed too (in different terms.)  But like
you said, it's a lot of extra complexity.  I suspected as much.  I dabbled
with prime and composite numbers as a way of representing interfaces and
narrowing searches, but didn't get far. ;-)

> So, again, defining the requirements precisely is important.  For example, 
> if different protocols really need different traversers, why not just adapt 
> to different traversal interfaces?

That's an interesting insight.  Adapters would provide IHTTPTraverser,
IFTPTraverser, etc.  A problem arises, though, when you want to register
and use a general ITraverser: getAdapter(foo, IHTTPTraverser) must never
return an adapter registered as providing only ITraverser.  So either the
adapter has to be registered many times (once for each traversal interface
in the system) or we have to call getAdapter() multiple times, each time
more general.

Even so, I think a solution along those lines would be better than what
we're doing now, putting traversal components in the view registry.

Shane