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

[Louis Madon]

Bruce Hoult wrote:
> 
> 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 agree, but isn't that what runtime exceptions are for?

> 
> 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)?

I think the semantics need to be really simple: if there's any doubt
throw an exception.  If the system starts making guesses about whether
this method or that method could handle it, it might get it wrong, and I
think it also makes reasoning about the program more difficult.

>  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 :-)

You're not suggesting explicit type tests inside foo(A, B) are you? 
Thats precisely the kind of thing we need to get away from.  I could
come along and define a new class AB that inherits from both A and B and
all of a sudden your typecase is broken.

Louis.