Python syntax in Lisp and Scheme

Erann Gat my-first-name.my-last-name at jpl.nasa.gov
Wed Oct 8 18:34:53 EDT 2003


In article <bm20rh$2t$1 at newsreader2.netcologne.de>, Pascal Costanza
<costanza at web.de> wrote:

> Christopher C. Stacy wrote:
> 
> > JAVA has multi-methods with non-congruent arglist.
> > (It doesn't have multiple inheritence, but that doesn't 
> > matter to dynamic type dispatching, except maybe in how 
> > you implement searching your handler tables.)  In JAVA, 
> > the correspondance of the "signature" of the function call
> > and the method definition are what's important;
> > and there are no restricting "generic functions".
> > 
> > public class RandomAccessFile extends Object,implements DataOutput {
> >   public void write(byte[] b) throws IOException;
> >   public void write(byte[] b, int off, int len) throws IOException;
> >   ...
> > }
> 
> Maybe this is just a terminological issue, but in my book these are not 
> multi-methods. In Java, methods with the same name but different 
> signatures are selected at compile time,

When the selection is done is immaterial.  The point is that it's done at
all.  There's no reason why the same algorithm that is used to select
methods at compile time can't also be used to select methods at run time. 
The claim that congruent argument lists are necessary for multi-method
dispatch is clearly false.

> and this is rather like having 
> the parameter types as part of the method name.

No.  It's the "system" keeping track of the types, not the user.  That's
the key.  The fact that C++ and Java just happen to do it at compile time
rather than at run time is a red herring.

> 
> This can lead to subtle bugs. Here is an example in Java:

These "subtle bugs" are a reflection of the limitation of compile-time
type inference in Java, not a limitation of multi-method dispatch with
non-congruent argument lists.

E.




More information about the Python-list mailing list