Comments on: Another solution to the Java equals/compareTo Problem (More or Less) http://enfranchisedmind.com/blog/2007/02/26/another-solution-to-the-java-equalscompareto-problem-more-or-less/ Robert Fischer and Brian Hurt on Punditry, Programming Languages, and Other Religious Issues Fri, 21 Nov 2008 04:00:07 +0000 http://wordpress.org/?v=2.6.3 By: Robert http://enfranchisedmind.com/blog/2007/02/26/another-solution-to-the-java-equalscompareto-problem-more-or-less/#comment-3525 Robert Tue, 27 Feb 2007 13:53:11 +0000 http://enfranchisedmind.com/blog/archive/2007/02/26/203#comment-3525 And one last thought before I let this go. A quick save for this implementation would be to define the equals and compareTo method to only work with objects of the same type. I think this was the conceptual usage of equals and compareTo for the original Java layout, and all the issues are neatly sidestepped at that point. And one last thought before I let this go. A quick save for this implementation would be to define the equals and compareTo method to only work with objects of the same type. I think this was the conceptual usage of equals and compareTo for the original Java layout, and all the issues are neatly sidestepped at that point.

]]> By: Robert http://enfranchisedmind.com/blog/2007/02/26/another-solution-to-the-java-equalscompareto-problem-more-or-less/#comment-3523 Robert Tue, 27 Feb 2007 13:48:11 +0000 http://enfranchisedmind.com/blog/archive/2007/02/26/203#comment-3523 Of course, the way I implement things hoses up the case where (x=a,y=b), (x=a,y=b,z=0) -- there, you might actually *WANT* them to be equal. Or you might not want to assume that the 2D point sits on the z=0 plane. Who knows. And that's really the rub, isn't it? Of course, the way I implement things hoses up the case where (x=a,y=b), (x=a,y=b,z=0) — there, you might actually *WANT* them to be equal. Or you might not want to assume that the 2D point sits on the z=0 plane. Who knows.

And that’s really the rub, isn’t it?

]]> By: Robert http://enfranchisedmind.com/blog/2007/02/26/another-solution-to-the-java-equalscompareto-problem-more-or-less/#comment-3522 Robert Tue, 27 Feb 2007 13:44:50 +0000 http://enfranchisedmind.com/blog/archive/2007/02/26/203#comment-3522 When I write hash values, I tend to associate each field with its own arbitrary binary value, which is then XORed with the natural hash of the calculation. The cute implementation is to define those at runtime using RandomUtils, and have that generator check to make sure we're not getting duplicates -- the more mundane version is to just generate a random number between MIN_INT and MAX_INT and hardcode that into the hash-code implementation, and for child classes to double-check the calculation. When I write hash values, I tend to associate each field with its own arbitrary binary value, which is then XORed with the natural hash of the calculation. The cute implementation is to define those at runtime using RandomUtils, and have that generator check to make sure we’re not getting duplicates — the more mundane version is to just generate a random number between MIN_INT and MAX_INT and hardcode that into the hash-code implementation, and for child classes to double-check the calculation.

]]> By: Brian http://enfranchisedmind.com/blog/2007/02/26/another-solution-to-the-java-equalscompareto-problem-more-or-less/#comment-3498 Brian Tue, 27 Feb 2007 01:57:36 +0000 http://enfranchisedmind.com/blog/archive/2007/02/26/203#comment-3498 Another comment I'll make- this problem shows up in C++ as well- the problem occurs wether the equality function is called equals or operator==. The difference is that in C++ there is no written contract that operator== has to abide by. For example, a == b does not necessarily have to imply b == a. Another comment I’ll make- this problem shows up in C++ as well- the problem occurs wether the equality function is called equals or operator==. The difference is that in C++ there is no written contract that operator== has to abide by. For example, a == b does not necessarily have to imply b == a.

]]> By: Brian http://enfranchisedmind.com/blog/2007/02/26/another-solution-to-the-java-equalscompareto-problem-more-or-less/#comment-3497 Brian Tue, 27 Feb 2007 01:30:05 +0000 http://enfranchisedmind.com/blog/archive/2007/02/26/203#comment-3497 Worse yet, the hash equals doesn't work. Consider the case you brought up in your original post on this- comparing a 3D point to a 2D point. Assume that you want to compare them equals if x3D = x2D, y3D = y2D, and z3D = 0. Unfortunately, for any reasonable hash value, the hash of (x, y, 0) will be different than the hash of (x, y). This is also assuming that the two classes use the same hash function, but that's a different problem. I am rapidly comming to the opinion that the best implementation is: <CODE> public boolean equals (Object them) { throw Exception("equals doesn't work! Use a comparator!"); } </CODE> However, this would likely not be popular in most Java shops. Worse yet, the hash equals doesn’t work. Consider the case you brought up in your original post on this- comparing a 3D point to a 2D point. Assume that you want to compare them equals if x3D = x2D, y3D = y2D, and z3D = 0. Unfortunately, for any reasonable hash value, the hash of (x, y, 0) will be different than the hash of (x, y). This is also assuming that the two classes use the same hash function, but that’s a different problem.

I am rapidly comming to the opinion that the best implementation is:

public boolean equals (Object them) {
throw Exception(”equals doesn’t work! Use a comparator!”);
}

However, this would likely not be popular in most Java shops.

]]>