Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > hashCode

Reply
Thread Tools

hashCode

 
 
Arne Vajhøj
Guest
Posts: n/a
 
      08-27-2012
On 8/21/2012 6:43 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <(E-Mail Removed)> wrote:
>> We are looking at two alternatives:
>> A) default functions properly but good performance requires an override
>> B) default gives good performance but may need an override to function
>> properly

>
> C) default hashCode() works perfectly well with default equals(), and only
> those with a specific requirement for equality, who thus need to override
> .equals(), anyway, also need to override hashCode() appropriately for
> their specific equality-relation.


That is just B in another wording.

Arne


 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      08-27-2012
On 8/27/12 4:04 PM, Arne Vajhøj wrote:
> On 8/21/2012 6:43 AM, Andreas Leitgeb wrote:
>> Arne Vajhøj <(E-Mail Removed)> wrote:
>>> We are looking at two alternatives:
>>> A) default functions properly but good performance requires an override
>>> B) default gives good performance but may need an override to function
>>> properly

>>
>> C) default hashCode() works perfectly well with default equals(), and
>> only
>> those with a specific requirement for equality, who thus need to
>> override
>> .equals(), anyway, also need to override hashCode() appropriately for
>> their specific equality-relation.

>
> That is just B in another wording.


However you word it.

The truth is that equals/hashCode should probably be overridden
together, or together remain default.

I find it somewhat disappointing that there are Comparable/Comparator
interfaces, but no Hashable/Hasher interfaces.

As it turns out, usually equals doesn't work well with subclasses
anyway, so to have an external "equals" predicate makes for a cleaner
abstraction.
 
Reply With Quote
 
 
 
 
markspace
Guest
Posts: n/a
 
      08-28-2012
On 8/27/2012 4:55 PM, Daniel Pitts wrote:

> I find it somewhat disappointing that there are Comparable/Comparator
> interfaces, but no Hashable/Hasher interfaces.



I think -- I'm not sure, but I believe -- the the ability to hash
something into a hash table (a symbol table, in some terminologies) was
considered so important and so fundamental to so many algorithms that it
was deemed intrinsic to the system. And therefore mandated for all objects.

For example, in C, one can always hash based on memory address. In Java
we don't have that option, so hashcode() takes the place of the
intrinsic property of an address.

Whereas the ability to sort or order objects was recognized as not being
intrinsic to all objects, so it was separated out. Sorting a list, or
ordering a tree, isn't something you can always do by default.

Just my two nickels here, and of course I'm guessing as to why
hashcode() is included in Object and not an interface.


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      08-28-2012
On Monday, August 27, 2012 5:03:37 PM UTC-7, markspace wrote:
> Daniel Pitts wrote:
>> I find it somewhat disappointing that there are Comparable/Comparator
>> interfaces, but no Hashable/Hasher interfaces.

>
> I think -- I'm not sure, but I believe -- the the ability to hash
> something into a hash table (a symbol table, in some terminologies) was
> considered so important and so fundamental to so many algorithms that it
> was deemed intrinsic to the system. And therefore mandated for all objects.


Right or wrong, that's plausible.

And a separate Hasher interface would be kludgey.

> For example, in C, one can always hash based on memory address. In Java
> we don't have that option, so hashCode() takes the place of the
> intrinsic property of an address.


That really makes sense. We have a nearly unique code for every object, and
in practical terms one is vanishingly unlikely to get duplicate identity hashes
within any given run.

> Whereas the ability to sort or order objects was recognized as not being
> intrinsic to all objects, so it was separated out. Sorting a list, or
> ordering a tree, isn't something you can always do by default.
>
> Just my two nickels here, and of course I'm guessing as to why
> hashcode() is included in Object and not an interface.


So to cap this topic, we have a default identity hash in the 'Object#hashCode()'
implementation that does a good job of distributing things in 'HashMap' and
the like, and matches the semantics of the default identity 'equals()'. The OP's
question as to whether one should substitute the degenerate hash gets a
resounding "NO!" One overrides 'hashCode()' for consistency with 'equals()'
exactly when the latter is overridden. If the type in question implements
'Comparable' then the 'compareTo()' method likewise should match, as should
'toString()' (in a somewhat looser sense of "match", perhaps, but not too loose).

All four methods speak to the semantics of sameness for the type in question,
and should be consistent with each other.

--
Lew
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      08-28-2012
On 8/27/2012 7:55 PM, Daniel Pitts wrote:
> On 8/27/12 4:04 PM, Arne Vajhøj wrote:
>> On 8/21/2012 6:43 AM, Andreas Leitgeb wrote:
>>> Arne Vajhøj <(E-Mail Removed)> wrote:
>>>> We are looking at two alternatives:
>>>> A) default functions properly but good performance requires an override
>>>> B) default gives good performance but may need an override to function
>>>> properly
>>>
>>> C) default hashCode() works perfectly well with default equals(), and
>>> only
>>> those with a specific requirement for equality, who thus need to
>>> override
>>> .equals(), anyway, also need to override hashCode() appropriately for
>>> their specific equality-relation.

>>
>> That is just B in another wording.

>
> However you word it.
>
> The truth is that equals/hashCode should probably be overridden
> together, or together remain default.


It should.

It must with the hashCode of today.

Arne

 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      08-28-2012
On 8/27/2012 8:03 PM, markspace wrote:
> On 8/27/2012 4:55 PM, Daniel Pitts wrote:
>
>> I find it somewhat disappointing that there are Comparable/Comparator
>> interfaces, but no Hashable/Hasher interfaces.

>
>
> I think -- I'm not sure, but I believe -- the the ability to hash
> something into a hash table (a symbol table, in some terminologies) was
> considered so important and so fundamental to so many algorithms that it
> was deemed intrinsic to the system. And therefore mandated for all
> objects.


Using Object as key is in my opinion rarely a good design.

And relevant more specific types defined in the Java library
could implement Hashable.

> Just my two nickels here, and of course I'm guessing as to why
> hashcode() is included in Object and not an interface.


It is a plausible explanation.

I think the Hashable interface would have been
good.

But the decision was made many years ago.

And .NET made the same decision!

Arne

 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      08-28-2012
On 8/27/2012 6:58 PM, Patricia Shanahan wrote:
> On 8/27/2012 5:03 PM, markspace wrote:
> ...
>> For example, in C, one can always hash based on memory address. In Java
>> we don't have that option, so hashcode() takes the place of the
>> intrinsic property of an address.

> ...
>
> In Java we have System.identityHashCode() which provides an address-like
> hash code for any object.



I think System.identityHashCode() is the (same as the) default
implementation for Object::hashCode(), yes?

So there's a small bit of evidence in support of the idea that
Object::hashCode() is meant to mimic the idea of just hashing on address.



 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      08-28-2012
On 8/28/2012 1:06 AM, Patricia Shanahan wrote:

> On 8/27/2012 9:19 PM, markspace wrote:
>> I think System.identityHashCode() is the (same as the) default
>> implementation for Object::hashCode(), yes?


>
> Yes, but it could have been written, with a slightly different
> explanation, without putting hashCode() in Object.



And then you get into situations like this:

if( object instanceof Hasher )
hash = ((Hasher) o).hashCode();
else
hash = System.identityHashCode( object );

And I think we all know to use polymorphism instead here. This is kind
of what I'm saying. The usefulness of a hash code was consider
intrinsic to any object, and they wanted to avoid the code above.
Therefore, Object::hashCode() becomes the design spec.


> I don't think you need such indirect evidence:
>
> "As much as is reasonably practical, the hashCode method defined by
> class Object does return distinct integers for distinct objects. (This
> is typically implemented by converting the internal address of the
> object into an integer, but this implementation technique is not
> required by the JavaTM programming language.) "



It doesn't really inform the reasons why hashCode() is part of Object
though. On that front, I'm speculating (i.e., making stuff up).

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      08-28-2012
Patricia Shanahan wrote:
> markspace wrote:
>
> ...
>
>> For example, in C, one can always hash based on memory address. In Java
>> we don't have that option, so hashcode() takes the place of the
>> intrinsic property of an address.

>
> ...


> In Java we have System.identityHashCode() which provides an address-like
> hash code for any object.


Which is simply a wrapper method for the 'Object#hashCode()' method.

"Returns the same hash code for the given object as would be returned by the
default method hashCode(), whether or not the given object's class overrides
hashCode()."

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      08-28-2012
markspace wrote:
> Patricia Shanahan wrote:
>> markspace wrote:
>> ...
>>> For example, in C, one can always hash based on memory address. In Java
>>> we don't have that option, so hashcode() takes the place of the
>>> intrinsic property of an address.

>> ...

>
>> In Java we have System.identityHashCode() which provides an address-like
>> hash code for any object.

>
> I think System.identityHashCode() is the (same as the) default
> implementation for Object::hashCode(), yes?


Why wonder when it's in the Javadocs?

Hm?

It is, in fact, required to be.

> So there's a small bit of evidence in support of the idea that
> Object::hashCode() is meant to mimic the idea of just hashing on address.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hashcode of primitive types Dimitri Pissarenko Java 5 01-29-2004 11:05 PM
Improving hashCode() to match equals() Marco Java 10 01-17-2004 09:55 PM
Designing hashCode() methods kelvSYC Java 1 12-24-2003 02:56 AM
equals and hashCode Gregory A. Swarthout Java 2 12-20-2003 12:34 AM
hashCode for byte[] Roedy Green Java 1 08-22-2003 02:08 AM



Advertisments