I can see how it could be done using some additional syntax similar to what ML uses, e.g.:
Guido> def f(a: Cat1): Guido> ...code for Cat1... Guido> else f(a: Cat2): Guido> ...code for Cat2... Guido> else f(a: Cat3): Guido> ...code for Cat3... Greg> As long as all the implementations have to be in one place, Greg> this is equivalent to Greg> def f(a): Greg> if belongstocategory(a, Cat1): Greg> ... Greg> elif belongstocategory(a, Cat2): Greg> ... Greg> elif belongstocategory(a, Cat3): Greg> ... Greg> so you're not gaining much from the new syntax. I'm not so sure. The code is alreasy somewhat simpler here, and it would be substantially simpler in examples such as def arctan(x): ... else arctan(y, x): ...
It might also be possible to modify a multimethod dynamically, e.g. later one could write:
def f4(a: Cat4): ...code for Cat4...
f.add(f4)
Greg> This sort of scheme makes me uneasy, because it means that any module Greg> can change the behaviour of any call of f() in any other Greg> module. It makes me uneasy because the behavior of programs might depend on the order in which modules are loaded. That's why I didn't suggest a way of defining the variations on f in separate places. -- Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark