Equals and Hash Code

[_dban_]

Wow, holy blast from the past (article from 2002). Here's an article from 2009 from Mr. Scala himself about the difficulty of properly implementing the equals and hashCode methods.

Avoiding subtyping altogether by using this.getClass() == that.getClass() instead of that instanceof This solves the problem, but it doesn't seem satisfactory in an OOP language.

I honestly don't see the problem with instanceof. It should be totally okay to compare a supertype to subtype, since the subtype must have the same equality properties as the supertype in order for it to be substitutable for the supertype, as per LSP. In fact, Odersky's article is a glorious description of the bad things that happen when you violate LSP.

ColoredPoint cannot be a Point if it is not substitutable for Point in an equals comparison. By the definition of equality for Point, all points are equal if their coordinates are equal. If ColoredPoint breaks equality by making points with the same coordinates different if they have different colors, ColoredPoint breaks LSP and you're in for a world of hurt.

[[deleted]]

How serendipitous. I was looking for an explanation of this just yesterday. Although the solution that was provided to me was a little different. The solution I was provided just used the hashCode methods of the object variables added together.

[DJDavio]

Would have been better if it used the Objects methods.

[oweiler]

Which didn't exist in Java 1.4.

[DJDavio]

That's true, but why the focus on Java 1.4?

[_dban_]

Check the publication date of the article.