Re: hashCode
On 8/31/2012 11:56 AM, Jim Janney wrote:
Eric Sosman <esosman@ieee-dot-org.invalid> writes:
[...]
Objects that compare equal must hash to the same value. It follows that
if the hash function uses a value, so must the comparison method.
Since java.lang.String had already been mentioned, it's sort
of too bad you didn't look at it before posting. Had you done so,
you'd have found that [1] hashCode() uses the private field `hash'
and [2] equals() does not.
If you want to play gotcha, it's sort of too bad you don't read this
newsgroup more often. I pointed out the use of the private field some
time ago, when we were discussing immutable classes.
If you'd rather argue on the actual issues, a cached result is not extra
information. The hashCode method in String doesn't return anything that
can't be computed from publically available information.
Right. Except hashCode() can arrange to compute the value
just once, while an external Hasher without access to the private
field would need to recompute it every single time. I never said
a Hasher could not compute a perfectly good hash code (for a sane
class, at any rate), just that it would have to forego benefits
that are available to an internal hashCode() method.
Are those benefits worth while? Sometimes yes, sometimes no.
Sun apparently believed that they were in fact worth while in the
case of java.lang.String (indeed, Bloch says String's hashCode()
received a lot of attention and went through multiple generations).
If you think caching String's hash is not worth the effort, I
encourage you to experiment with a variant rt.jar that omits the
cache, run some timings, and report the results.
To the other issue, about whether HashMap et al. should
have a constructor taking an externally-supplied Hasher as an
alternative to using the key's own hashCode() -- well, HashMap
is not a final class. Have at it!
(Nor, by the way, do I deny the potential utility of such
a hashed map. It could, for example, have been used to get
around the inadequacies of String.hashCode() in early Java ...)
--
Eric Sosman
esosman@ieee-dot-org.invalid