>> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4