Discussion: new operators for numerical computation

[Greg Ewing]

Eric Lorenzo wrote:
> 
> So yeah, you're
> reducing encapsulation a bit with multi-methods, but in my view,
> that's okay,

The difficulty isn't really one of encapsulation, it's one
of namespace management.

In current Python, you can always (assuming no nasty hackery
has been done) fairly easily find the piece of code that will 
be called by a particular function or method or operator call, 
if you know the dynamic type of the arguments. If it's a plain
function call, you can trace it through the import statements,
and if it's a method or operator, it'll be found somewhere
on the inheritance chain of the receiver's class.

I assume nobody disputes that this is a very useful property --
we all know that Python's module namespace system is a good
idea.

It's hard to see how to implement multiple dispatch in a way
that preserves this property, while still being flexible
enough to solve the kinds of problems that multiple dispatch
is supposed to solve. For instance, to be able to add a new
operation on some combination of existing classes, it must
be possible to define a multimethod on them outside of any
of those classes. But then it could be defined anywhere,
and knowing the classes of the operands gives you no clue
as to where to look for the definition.

I had a look at that paper on a multimethod extension to
Java that was mentioned here, hoping to find a solution to
this problem, as the abstract seems to suggest they have
addressed it.

But, as far as I can tell, they haven't. Under their scheme,
it's still possible for a method call to invoke a piece of 
code in some module that is not related in any obvious way 
to the one where the call is made, or the ones where the
classes involved are defined.

-- 
Greg Ewing, Computer Science Department, 
University of Canterbury, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg