Multimethods

[Paul Prescod]

Neel Krishnaswami wrote:
> 
> ....
> 
> So multimethods. In ordinary OO programming, you can think of a method
> as a set of functions, and the function body that's chosen is based on
> the runtime type of the first argument.

You could, but Python exposes so much of the underlying implementation
that this is not a very intuitive way to think about it. In particular,
every instance of a class could have a *unique method* frob simply by
assigning to the frob attribute. So you have to think of the function
body being selected not based on runtime type but rather on the
particular runtime instance's identity (e.g. "id()").

So it isn't clear to me how you extend this into multimethods. If Python
dispatch is not type-based to start with making a mechanism that is
doubly type-based seems inconsistent. I mean  the first step would be to
make a form of Python method invocation that is type-based even for one
argument.

def foo( int a ):
	....

def foo( float b):
	...

-- 
 Paul Prescod - Not encumbered by corporate consensus
New from Computer Associates: "Software that can 'think', sold by 
marketers who choose not to."