Received: by 10.66.74.225 with SMTP id x1mr1932502pav.45.1346455582258; Fri, 31 Aug 2012 16:26:22 -0700 (PDT)
Received: by 10.68.189.228 with SMTP id gl4mr2145129pbc.4.1346455582245; Fri, 31 Aug 2012 16:26:22 -0700 (PDT)
Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!4no1255810pbn.1!news-out.google.com!a8ni4189115pbd.1!nntp.google.com!r4no1317779pbs.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.java.programmer
Date: Fri, 31 Aug 2012 16:26:22 -0700 (PDT)
In-Reply-To: <ydnipbysmzv.fsf@shell.xmission.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T
NNTP-Posting-Host: 69.28.149.29
References: <563f186a-edb3-4311-ae48-3af7decfce2c@googlegroups.com> <50317b03$0$281$14726298@news.sunsite.dk> <slrnk36phl.u9l.avl@gamma.logic.tuwien.ac.at> <503bfd0f$0$282$14726298@news.sunsite.dk> <CNT_r.5387$pd4.3890@newsfe21.iad> <k1h1sp$qdf$1@dont-email.me> <PPadnUGBC8NIuKHNnZ2dnUVZ_gudnZ2d@earthlink.com> <k1hgt4$vk5$1@dont-email.me> <BbednWMHAfFh5qHNnZ2dnUVZ_r-dnZ2d@earthlink.com> <k1ir2n$au0$1@dont-email.me> <3zc%r.5945$pd4.2658@newsfe21.iad> <k1jm6i$s5k$1@dont-email.me> <zSs%r.2724$Wh5.2588@newsfe14.iad> <k1lo7d$835$1@dont-email.me> <k1oqsq$p0u$1@dont-email.me> <k1p4rh$im0$1@dont-email.me> <k1p6vk$s4p$1@dont-email.me> <ydnzk5brte4.fsf@shell.xmission.com> <k1qlpa$kjv$1@dont-email.me> <ydnvcfzrr5r.fsf@shell.xmission.com> <c230ca57-ae64-4a1c-8799-52bb2a7641e1@googlegroups.com> <ydnipbysmzv.fsf@shell.xmission.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <cac34249-3fbb-4ddf-b1fa-903375e51c2e@googlegroups.com>
Subject: Re: hashCode
From: Lew <lewbloch@gmail.com>
Injection-Date: Fri, 31 Aug 2012 23:26:22 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: csiph.com comp.lang.java.programmer:18491

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