Re: hashCode
Jim Janney wrote:
Once again: once again, there is no reason why String can't define a
hashCode method for instances of Hasher to call. No need to forego
anything.
And, indeed, once again once again, 'String' has already provided such a method.
I don't see what the big to-do is about 'Object' having 'hashCode()' defined. It's
just fine as an address proxy in the default implementation, never mind its use
for hashing, and the override to provide value equality is exactly the effort needed
for classes that need a "real" hash, only at least it's in the very class whose logic
it is, rather than artificially separated into a separate 'Hasher' type.
So once again once again, the existing mechanism shows itself to be at worst
not much worse than the proposal.
Also, once again once again, the hash must match the idea of equality for the
type. I don't notice anyone arguing (yet) that 'equals()' should not be present
in 'Object'. Best practices once again once again promote keeping 'equals()',
'hashCode()', 'compareTo()' (where present) and 'toString()' consistent with
each other.
So once again once again once again once again we see the status quo
being pretty much equivalent once again once again to the proposal
once again.
--
Lew
once again
again