[munich-lisp] multimethods, generic functions, multiple dispatch, ...

[Andreas Hauser]

Christian.Schuhegger wrote @ Sun, 11 Sep 2005 16:48:49 +0200:
> Andreas Hauser wrote:

> > And why don't you need:
> > (defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle))
> > ?
> 
> this is because collission of two objects is symmetric:
>   a collides with b <=> b collides with a
> and i do not have to implement the same code again.

I thought you had meant, that you don't need the second method at all.
Like having an alias in the symbol table or something.
I could imagine in a cool language you would only need one method
and have some way to specify that the argument order doesn't matter.
In Lisp i would at least have expected something like:
(defmethod-all-combinations do-shapes-collide ((shape1 Circle) (shape2 Triangle))
where defmethod-all-combinations would produce all combinatios of the
arguments, namely:
do-shapes-collide ((shape1 Circle)   (shape2 Triangle))
do-shapes-collide ((shape2 Triangle) (shape1 Circle))

And from the way you presented this at the biergarden, i tought, that
CL even had some builtin magic for that case.

> but this overloading of methods is something "compile time" and not "run 
> time", e.g. if you would have some code similar like this:
> -- snip start --
> public class CollisionDetectionAlgorithm {
>      public static boolean collides(Shape s1, Shape s2) {...;}// throw a 
> runtime exception
>      public static boolean collides(Triangle s1, Circle s2) {...;}
>      public static boolean collides(Triangle s1, Square s2) {...;}
> 
>      public static void main(String[] args) {
> 	Shape s1 = new Triangle();
> 	Shape s2 = new Circle();
> 	System.out.println(collides(s1,s2));
>      }
> }
> -- snip end --
> you would end up with the first collides method being called which would 
> throw a runtime exception. the only runtime type polymorphism that java 
> knows is subtype type polymorphism which only reacts on the type of the 
> implicite 'this' type. the calls to the overloaded methods are fixed at 
> compile time.

Even if Java was more dynamic, i don't see, why in this case it should not
match the collides(Shape, Shape) signature, when you explicitly declare s1
and s2 to be of Shape. You would need them do be declared with the
signatures you want to match.

public static void main(String[] args)
{
 	Triangle s1 = new Triangle();
 	Circle s2 = new Circle();
 	System.out.println(collides(s1,s2));
}

I don't get the point.


Andy