Multiple dispatch again

[Samuele Pedroni]

From: "David Mertz" <mertz at gnosis.cx>


> I've got to thinking about multimethods/multiple dispatch lately.  I
> wonder if Pythonistas have some futher opinions on the use of these.
> Actually, part of it is that I'd -really- like to better understand use
> cases for multiple dispatch.  As a trick, I can see it has a certain
> elegance, but little rock/paper/scissors toys are not, finally,
> compelling.

1) You can think about operators as multimethods vs. __add__ __radd__ .
2) Think about the visitor pattern once who have multiple dispatch.
3) Suppose you want the presentation of objects to change depending on
"context"
      pres(ctxt,obj)
4) If you have also dispatch on singletons and not only types (both Dylan
and CLOS have that too):
   e.g. PEP 246 or variations are trivially implemented
...

> There are a few things that I had particularly in mind.  In reading
> about Dylan, I found that it has a method named 'next-method( )' to
> propogate dispatch from the closest match to more distant ones.  You can
> control whether you want this to happen by including that method, or
> not.  Take a look at:
>
>     http://www.tpk.net/~ekidd/dylan/multiple-dispatch.html
>
> In my code, I added the facility to propogate dispatch.  Using the
> simple example that was a topic of conversation here 6 weeks ago, you
> can make a call like:
>
>     beats.add_rule((Fire,Thing), firepower, next_meth=AT_END)
>
> I give you options to propogate dispatch either before or after the code
> within the current method execution.

I think a multi-argument generalization of super (similar also to Cecil
resend

http://www.cs.washington.edu/research/projects/cecil/www/pubs/cecil-spec.htm
l

), would be the most flexible, pythonic solution.


> As well, I decided to make dispatch resolution order configurable.
> Hochberg's example was perhaps naive in fixing resolution order
> according to definition order.  That seems a little fussier than I would
> want.  So I made that configurable as well, and provide four sample
> resolution functions.  Two are naively definition-order based (either
> forward or reversed).  But two others are perhaps better candidates:
> 'lexicographic_mro()' and 'weighted_mro()'.  If I understand correctly
> (which I may not), the first follows Dylan, the second follows Damian
> Conway' Class::Multimethods.  I would be interested to understand other
> examples, particularly CLOS.  I have little intuition about what is the
> "right" answer.

lexicographic is default CLOS approach, in Dylan:

given B isa A,  then the signatures

(B,A)
(A,B)

would be ambiguous. (but if I recall correctly some(one) Dylan impl use the
CLOS ordering and not the Dylan one, oh well).

Unless you have only single inheritance and so you don't need linearization
of class hierarchies, I don't think the weighted approach
is manageable.

> Since I allow propogated dispatch, I had to decide what to do with
> results from the function calls.  I decided to accumulate all returned
> values into a list, and let the user pick what they want.  So for
> example:
>
>     <fire, fire>      ['Fire always wins!', 'Fire always wins!', 0]
>
> But for a non-propogating rule, the list has a single member:
>
>     <rock, scissors>  [1]
>
> If you stick to either 'SKIP' or 'AT_END' propogation, you can count on
> index 0 of the return being the most specific function's value.  Or if
> conversely, you like 'AT_START', you can use index -1.  If you mix the
> two styles, it could become complicated to find relevant return values.
>

which applicable methods to call and how to combine the results is dealt in
CLOS with method combinations.

A summary of CLOS can be found here:

http://www.dreamsongs.com/NewFiles/ECOOP.pdf

regards.