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

[Bruce Hoult]

In article <381A421D.D8C8E22F at bigfoot.com>, Louis Madon
<madonl at bigfoot.com> wrote:

> [I'm cross-posting this to comp.lang.dylan as I think the Dylaners' may
> be able to cast more light on this and/or correct any short-comings in
> my thinking] 
> 
> 
> In the beginning Greg Ewing wrote:
> 
> > 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?
> 
> 
> Several people said its "ambiguous".

Interesting case.

Certainly it's ambiguous.

I note that the ambiguity can arise *only* if some module that (directly
or indirectly) calls foo() also (directly or indirectly) depends on both
AA and BB.

For example, you suggested that maybe something in module X calls
something in module Y, passing it a BB.  Module Y creates an AA (which X
doesn't know about) and calls foo(AA, BB).  oops.  The only place that
this problem can be detected at compile-time is in module X, and then only
if the compiler knows that module Y imports both AA and foo EVEN IF IT
DOESN'T RE-EXPORT THEM.  This seems like a big ask.

I'm wondering what the semantics of the exact situation are.  Will the
right result occur if foo(A, BB) or foo(AA, B) is called for arguments of
type (AA, BB)?  If not then perhaps foo() is trying to do too much and
should be split up?  In particular, perhaps there should instead be a
bar(A) and baz(B) and just a single, generic, version of foo(A, B) that
calls bar(A) and baz(B) as part of its operation.  In which case the
implementator of AA should make a bar(AA) and the implementatior of BB
should make a baz(BB). And then all is sweetness and light :-)

-- Bruce