Re: hashCode
On Friday, August 31, 2012 8:56:50 AM UTC-7, Jim Janney wrote:
Eric Sosman <esosman@ieee-dot-org.invalid> writes:
On 8/31/2012 11:08 AM, Jim Janney wrote:
Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> writes:
On 31/08/2012 03:43, Eric Sosman allegedly wrote:
On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
[...]
As an example of why a hasher might want access to a strictly-private
field, I offered String: [...]
Imposing that classes should expose all information "relevant" (says
who??) to hashing is utter rubbish IMNSHO.
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.
But it does impose a need for the hash function to access a private method
so that it can return that value faster. Denying access to the private member
would kill that optimization, one that any type of immutable object might want
to use.
That is the motivation for requiring access to private members.
Your anger is misplaced, as your recent post rejects that scenario, implying
that the only reason to use private members in 'hashCode'-alikes is for
calculation of the value.
--
Lew