Re: hashCode() for Custom classes
Peter Duniho wrote:
Of course they won't. But that's not the point. Let's say you have a
hash table that holds Objects. That is, things of type Object. You
could obviously mix and match different classes in such a table.
Instances from different classes will never compare as equal, but it
would improve performance to ensure that they also don't have hash codes
that collide.
That is true. For example, Patricia elucidated Sets and Lists. But those use
what one might deem a "natural" hash code for their contents, that emergently
reduces the likelihood of collisions. More accurately, it pushes the problem
onto the base type's equality and hashing.
Another point with respect to Set is that the contract is spelled out at the
interface level. You're still going to run into trouble if you try to predict
collision rates on hashCode()s between, say, a Set and a List.
For what it's worth, I don't think it required a lot of imagination
to come up with the example. So feel free to withhold your credit if you like. :)
The imagination part comes into play because a whole lot of effort has gone
into Java to make it easier to specialize Collections by narrower types than
Object. It isn't that it took imagination to come up with the example so much
as to imagine that it's a useful one. The push seems to be away from
comparing incomparable objects, not increasing inter-class mingling like that.
It's really not all that uncommon to have collections that include mixed classes.
They are more commonly collections of some intermediate base class,
rather than just Object (thus Lasse's use of the phrase "similar classes").
But if you can reduce the chance of hash codes colliding between different
classes by seeding each class differently, you've just bought yourself a
Typically the reduction in collision comes about by having the hashCode()
mirror the equality comparison. There is absolutely no need for such seedy
seeding. For example, Sets can use a concatenation of their elements'
hashCode()s without regard for any special seeding - in fact, to seed them
differently based on class would ruin the hash.
performance improvement (whether it's always significant or not is a different question...but it could be).
It won't be.
--
Lew