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

Groups > comp.lang.java.programmer > #17795 > unrolled thread

Re: hashCode

Back to article view | Back to comp.lang.java.programmer

Contents

  Re: hashCode "Lew" <lew@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
    Re: hashCode "Lew" <lew@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
    Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
      Re: hashCode "Lew" <lew@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000

#17795 — Re: hashCode

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

  To: Jan Burse
From: Lew <noone@lewscanon.com>

Jan Burse wrote:
> Maybe it would make sense to spell out what the contract
> for hashCode() is. Well the contract is simply, the
> following invariant should hold:
>
>     /* invariant that should hold */
>     if a.equals(b) then a.hashCode()==b.hashCode()

True, but if you read the specification for 'hashCode()' fully, that is not the 
entire contract, only the compiler-enforceable part of it.

The entire specification requires that as much as feasible, the 'Object' 
implementation distinguish distinct instances, and that the method generally 
support 'HashMap', which promises O(1) 'get()' and 'put()' with a "proper" 
(i.e., compliant) 'hashCode()'.

--
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

[toc] | [next] | [standalone]

#17796

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

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

Lew wrote:
> Jan Burse wrote:
>> Maybe it would make sense to spell out what the contract
>> for hashCode() is. Well the contract is simply, the
>> following invariant should hold:
>>
>>     /* invariant that should hold */
>>     if a.equals(b) then a.hashCode()==b.hashCode()
>
> True, but if you read the specification for 'hashCode()' fully, that is not
> the entire contract, only the compiler-enforceable part of it.

Oooops!

I made a mistake.

Not even that is compiler-enforceable.

--
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

[toc] | [prev] | [next] | [standalone]

#17800

  To: Lew
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
ove-m2z-this>

  To: Lew
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <arne@vajhoej.dk>

On 8/11/2012 7:34 PM, Lew wrote:
> Jan Burse wrote:
>> Maybe it would make sense to spell out what the contract
>> for hashCode() is. Well the contract is simply, the
>> following invariant should hold:
>>
>>     /* invariant that should hold */
>>     if a.equals(b) then a.hashCode()==b.hashCode()
>
> True, but if you read the specification for 'hashCode()' fully, that is
> not the entire contract, only the compiler-enforceable part of it.
>
> The entire specification requires that as much as feasible, the 'Object'
> implementation distinguish distinct instances, and that the method
> generally support 'HashMap', which promises O(1) 'get()' and 'put()'
> with a "proper" (i.e., compliant) 'hashCode()'.

Two wrong statements.

It says that the method is defined to support HashMap

And HashMap does not guarantee O(1) with a correct hashCode - it guarantee that 
for one that return good distributed values.

Arne

-+- 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

[toc] | [prev] | [next] | [standalone]

#17810

  To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: "Lew" <lew@1:261/38.remove-m2z-this>

  To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: Lew <noone@lewscanon.com>

Arne Vajh-,j wrote:
> Lew wrote:
>> Jan Burse wrote:
>>> Maybe it would make sense to spell out what the contract
>>> for hashCode() is. Well the contract is simply, the
>>> following invariant should hold:
>>>
>>>     /* invariant that should hold */
>>>     if a.equals(b) then a.hashCode()==b.hashCode()
>>
>> True, but if you read the specification for 'hashCode()' fully, that is
>> not the entire contract, only the compiler-enforceable part of it.
>>
>> The entire specification requires that as much as feasible, the 'Object'
>> implementation distinguish distinct instances, and that the method
>> generally support 'HashMap', which promises O(1) 'get()' and 'put()'
>> with a "proper" (i.e., compliant) 'hashCode()'.
>
> Two wrong statements.
>
> It says that the method is defined to support HashMap
>
> And HashMap does not guarantee O(1) with a correct
> hashCode - it guarantee that for one that return
> good distributed values.

Granted.

--
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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web