Multiple dispatch again
David Mertz
mertz at gnosis.cx
Fri Jan 3 13:49:17 EST 2003
<David Mertz>
|> Now I can easily imaging that a method body would want to call on some
|> -specific- function that happened to be one of the multimethods.
"Samuele Pedroni" <pedronis at bluewin.ch> wrote previously:
|It really seems that the notion of multiple dispatching fill your mind
|with FUD <wink>.
Nah... my mind already becomes filled with FUD when I think of single
dispatch. My naivety doesn't need the extra wrinkle.
|Your line of reasoning could be equally applied to single dispatch:
In my defense though, there IS a difference. Every new-style child
class HAS a superclass--if nothing else, 'object' (or 'type'). If I
define some rules for multiple dispatch, I have no way of knowing within
the function bodies whether there even *is* a 'multi_super()' method to
call. And whether there is can change at runtime (actually, I could
change it at runtime within that very function body, but that would be
perverse).
The way I handle things in my current implementation (only propogating
dispatch AT_END or AT_START) already includes generic guards to prevent
non-existing less specific methods from being called. With a user
controlled multi_super(), you would need to add your own guards, and
change the flow to account for contingencies:
def semi_specific(this, that):
...do stuff...
try: # maybe there is *some* less specific method
val = multi_super()
except NothingLessSpecificError:
try_to_fix_things()
...more stuff...
Calling super() doesn't run into this problem. Now I -could- try to do
something "safe" in multi_super() as a fallback. A 'pass' is pretty
safe from an execution perspective. But if 'semi_specific()' wants a
return value, there is no way a fallback can guess a usuable value.
Yours, David...
--
mertz@ _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis _/_/ Postmodern Enterprises _/_/ s r
.cx _/_/ MAKERS OF CHAOS.... _/_/ i u
_/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/ g s
More information about the Python-list
mailing list