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

[Amit Patel]

 Louis Madon  <madonl at bigfoot.com> wrote:
| Greg Ewing wrote:
| > I'm a bit bothered by the idea that *adding* a new
| > method could cause previously valid calls to become
| > invalid. If I have only foo(A, B) and foo(AA, B)
| > defined, then calling foo(AA, BB) is okay. But if
| > I add a foo(A, BB), then all my existing foo(AA, BB)
| > calls, anywhere in the program, suddenly become ambiguous.
| 
| This scenario is telling you something about your architecture: perhaps
| you shouldn't be calling foo(AA, BB) or perhaps you should do some
| refactoring of the class model or perhaps you need to add a specific
| foo(AA, BB) method.  IMHO, this process helps to produce a better
| architecture.

I don't know I'm calling foo(AA, BB).  All I know is that I have an "A
like" object and a "B like" object (Python examples: file-like object
and sequence).  I then call foo on these two arguments, and the system
complains.

Therefore it can't be my fault when the foo(AA, BB) call fails.

My caller (1) doesn't know I'm calling foo (after all, why should he
know the implementation details of my class?), and (2) only gave me
one of the two arguments, and therefore is unaware of the combination
that is about to take place.

Therefore it can't be my caller's fault when foo(AA, BB) fails.

When defining foo(AA, B), the author of AA may not know about foo(A,
BB), so it can't be AA's fault if the call fails.

When defining foo(A, BB), the author of BB may not know about foo(AA,
B), so it can't be BB's fault if the call fails.


Everyone wrote "correct" code but when it's put together it fails.
That doesn't scale well.  :(


     - Amit