Multiple dispatch (Re: Q: Python 2.0 preliminary features?)

[Neel Krishnaswami]

Greg Ewing <greg.ewing at compaq.com> wrote:
>Multiple dispatch is an attractive idea, but it makes me uneasy.
>One reason is that it's not clear what the rules should be.
>
>Suppose AA is a subclass of A, and BB is a subclass of B,
>and there are methods defined for the combinations
>foo(A, B), foo(AA, B) and foo(A, BB).
>
>Now, if you make a call with the combination foo(AA, BB),
>which method should get called?

None of them; an "ambiguous method" exception should be raised. (Or if
you are in a statically-typed language ambiguous method dispatches can
be a compile-time error.) Seriously, an ambiguous method dispatch is a
sign of a problematic design.

The corresponding code in a singly-dispatching language is likely to
be a manual implementation of multiple dispatch using type tests on
the non-receiver arguments. IMO this is an accident waiting to happen,
since the method chosen can depend on the details of the order of the
type tests.

>If you have multiple dispatch *and* multiple inheritance,
>things get just too hairy to contemplate. I tried to devise
>a set of rules for this case once, but my brain got dangerously
>close to exploding and I had to give up...

I have done some programming in Dylan (which has MD and MI), and I
have never run into the problems you describe. I suppose that in
poorly-designed code it's possible, but the corresponding problems of
proliferating typecases and code duplication in singly-dispatching and
single-inheritance languages are sufficiently worse that I prefer MD
and MI.

Mileage varies, I guess.


Neel