Andreas Hauser wrote:

Christian.Schuhegger wrote @ Sat, 10 Sep 2005 08:58:48 +0200:

You seem to have forgotten to show the actual Lisp code.

sorry :)

(defmethod do-shapes-collide-p ((shape1 Triangle) (shape2 Circle)) (...)) (defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle)) (do-shapes-collide-p shape2 shape1)) (defmethod do-shapes-collide-p ((shape1 Triange) (shape2 Square)) (...)) ...

...

class Triangle implements Shape { public boolean collidesWith(Shape other) { other.collidesWithTriangle(this); } ...; public boolean collidesWithCircle(Circle s) {...;} public boolean collidesWithSquare(Square s) {...;} ...; }

While having methods with the same name but different signatures is certainly something i like, maybe in this case you just have problems with the objects you designed. I guess, we all know Java is limited, but let's not forget, they call it a feature.

class Triangle implements Shape { public 2Dspace space() { 2DSpace my_space = xy[screen.x_dim][screen.y_dim]; // fill the matrix with pixels the Triangle occuppies return my_space; } public boolean collidesWith(Shape other) { return overlap(other.space, this.space); } }

So first, generalize the properties of your objects and then let them interact. I would also say that colliding and especially overlap() is something that the Object World should do.

and what do you do if you talk about vector objects and not pixel objects :)

Andreas Hauser wrote:

...

(defmethod do-shapes-collide-p ((shape1 Triangle) (shape2 Circle)) (...)) (defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle)) (do-shapes-collide-p shape2 shape1)) (defmethod do-shapes-collide-p ((shape1 Triange) (shape2 Square)) (...)) ...

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.

It must be serialized somewhere (in Object World ?). Do the collision there.

this is why i suggested:

probably it is best factored out in a third CollisionDetectionAlgorithm class which only contains static methods for each combination of shapes.

and you are right:

But it seems Java can do methods with different sigantures:

public class foo { public foo() { }

public void bar(int i)
{
    System.out.println(i + 1);
}

public void  bar(String s)
{
    System.out.println(s + " world");
}

public static void main(String args[])
{
    foo f = new foo();
    f.bar(12);
    f.bar("Hello");
}

}

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.