Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #17837

Re: hashCode

Show all headers | View raw

  To: Arne Vajhøj
From: "Lew" <lew@1:261/38.remove-nlb-this>

  To: Arne Vajhoj
From: "Lew" <lew@1:261/38.remove-m2z-this>

  To: Arne Vajhoj
From: Lew <noone@lewscanon.com>

On 08/10/2012 04:30 PM, Arne Vajh-,j wrote:
> On 8/10/2012 6:32 PM, Lew wrote:
>> bob smith wrote:
>>> Now, there are cases where you HAVE to override it, or your code is very
>>> broken.
>>
>> No.
>
>> As long as 'hashCode()' fulfills the contract, your code will work -
>> functionally. But a bad
>> 'hashCode()' could and likely will noticeably affect performance. There is
>> more to correctness
>> than mere functional conformance.
>
> If the code per specs is guaranteed to work then it is correct.
>
> Good (or just decent) performance is not necessary for code to
> be correct.
>
> At least not in the traditional programming terminology.
>
> In plain English maybe.

I see your point, but that is not to say that the specs exclude performance 
considerations.

In the case of 'hashCode()', the Javadocs do say, "This method is supported for 
the benefit of hash tables such as those provided by HashMap."
<http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()>

The key question here is how you define "benefit". I argue that a hash code 
that is constant does not benefit, say, a 'HashMap' because one of our desired 
uses is constant-order retrieval.

"This implementation provides constant-time performance for the basic 
operations (get and put), assuming the hash function disperses the elements 
properly among the buckets."
<http://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html>

Each specification refers to the other. Ergo they are meant to be considered 
together. Taken together, the documentation clearly specifies that "correct" or 
"proper" includes performance considerations. Therefore, by what you say, the 
simple "return 1;" is not correct.

It certainly would not be correct for the 'Object' implementation. "As much as 
is reasonably practical, the hashCode method defined by class Object does 
return distinct integers for distinct objects." [op. cit.]

As you say, Arne, "correct" means it follows the spec. The OP's suggested 
implementation violates the spec on two fronts.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

-+- BBBS/Li6 v4.10 Dada-1
 + Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

-+- BBBS/Li6 v4.10 Dada-1
 + Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: hashCode "Lew" <lew@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000
  Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000
    Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000
      Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000
        Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000

csiph-web