Re: hashCode
On 8/10/2012 3:22 PM, bob smith wrote:
....
Better in the sense that you would never HAVE to override hashCode.
Now, there are cases where you HAVE to override it, or your code is very broken.
I've decided to go back to this message, because I feel the key issue is
the circumstances under which hashCode would need to be overridden if
Object's version returned a constant, compared to the current situation.
If Object's hashCode returned a constant, in practice anyone using an
object as a key in a hash structure would want it overridden with one
that has at least some chance of using multiple buckets. Without that
property, a HashMap is an over-complicated, space-wasting cousin of a
linked list.
The problem with this is that the programmer who knows that Widget
instances are going to be used as HashMap keys does not necessarily
control the Widget implementation. The programmer writing Widget has no
idea whether it will ever be used as a HashMap key, and therefore no way
of knowing whether it is safe, assuming Widget inherits the Object
equals, to also inherit the Object hashCode.
Now compare to the current situation. The programmer implementing Widget
decides whether to inherit a superclass equals or to write a
Widget-specific equals. That programmer can assume the superclass has a
hashCode that would be effective for a HashMap key, and only has to
override hashCode if they are overriding equals.
In practice, it is a long time since I've written a hashCode manually.
Generally, when I decide to override equals I tell Eclipse to generate
an equals/hashCode pair based on the fields that control whether two
instances are equal. Overriding hashCode is no additional work given
that I would be telling Eclipse to generate an equals based on those
fields anyway.
To me, the current situation seems "better".
Patricia