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

hashCode

Started by	bob smith <bob@coolfone.comze.com>
First post	2012-08-10 08:47 -0700
Last post	2012-08-12 17:11 -0400
Articles	20 on this page of 106 — 20 participants

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

  hashCode bob smith <bob@coolfone.comze.com> - 2012-08-10 08:47 -0700
    Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 12:13 -0400
      Re: hashCode markspace <-@.> - 2012-08-10 10:13 -0700
        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 13:38 -0400
          Re: hashCode rossum <rossum48@coldmail.com> - 2012-08-11 10:36 +0100
    Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-10 12:34 -0400
      Re: hashCode bob smith <bob@coolfone.comze.com> - 2012-08-10 15:22 -0700
        Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-10 15:32 -0700
          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:30 -0400
            Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:24 -0700
              Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:15 -0400
                Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:29 -0400
                  Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 22:43 -0400
                    Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:54 -0400
                      Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 21:46 -0700
                        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 16:53 -0400
                        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:00 -0400
        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:27 -0400
          Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-12 17:06 +0200
            Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 16:59 -0400
              Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-13 19:17 +0200
                Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-19 19:42 -0400
                  Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-21 10:30 +0000
                Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-19 19:47 -0400
                  Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-21 10:43 +0000
                    Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 19:04 -0400
                      Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-27 16:55 -0700
                        Re: hashCode markspace <-@.> - 2012-08-27 17:03 -0700
                          Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-27 17:49 -0700
                          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 21:37 -0400
                          Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-27 18:58 -0700
                            Re: hashCode markspace <-@.> - 2012-08-27 21:19 -0700
                              Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-28 01:06 -0700
                                Re: hashCode markspace <-@.> - 2012-08-28 09:19 -0700
                                  Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-28 16:33 -0700
                                    Re: hashCode markspace <-@.> - 2012-08-28 17:02 -0700
                                      Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 11:06 -0700
                                        Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 14:49 -0400
                                          Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 13:40 -0700
                                            Re: hashCode Gene Wirchenko <genew@ocis.net> - 2012-08-29 18:02 -0700
                                          Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-08-31 00:52 +0200
                                            Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-30 21:43 -0400
                                              Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-30 21:52 -0400
                                              Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-08-31 04:18 +0200
                                                Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:08 -0600
                                                  Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 11:38 -0400
                                                    Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-31 17:55 +0200
                                                    Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:56 -0600
                                                      Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 14:32 -0400
                                                        Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 14:38 -0600
                                                      Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-31 15:33 -0700
                                                        Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 16:41 -0600
                                                          Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-31 16:26 -0700
                                                            Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-09-02 11:54 -0600
                                                              Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-09-03 00:47 +0200
                                                                Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-09-03 21:44 -0600
                                              Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:08 -0600
                                                Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-31 17:58 +0200
                                        Re: hashCode markspace <-@.> - 2012-08-29 11:51 -0700
                                          Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 13:28 -0700
                                            Re: hashCode markspace <-@.> - 2012-08-29 16:05 -0700
                                              Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 16:23 -0700
                                                Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 20:56 -0400
                                                  Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-30 11:19 +0200
                                                  Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-30 10:03 -0700
                                                    Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-30 18:34 +0000
                                              Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-30 08:11 -0600
                                                Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-30 10:06 -0700
                                              Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-30 19:16 -0400
                              Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 13:58 -0700
                            Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 13:56 -0700
                              Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-28 14:07 -0700
                                Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 14:38 -0700
                        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 21:12 -0400
        Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 07:58 -0400
          Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:29 -0700
            Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:16 -0400
        Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 03:46 -0700
        Re: hashCode Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-08-12 12:23 -0400
          Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 09:40 -0700
            Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-12 13:59 -0400
              Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 11:17 -0700
            Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:02 -0400
          Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 19:03 +0200
    Re: hashCode Roedy Green <see_website@mindprod.com.invalid> - 2012-08-10 12:17 -0700
      Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-10 12:45 -0700
        Re: hashCode Roedy Green <see_website@mindprod.com.invalid> - 2012-08-11 04:54 -0700
          Re: hashCode Joerg Meier <joergmmeier@arcor.de> - 2012-08-11 18:25 +0200
            Re: hashCode Mike Winter <usenet@michael-winter.me.invalid> - 2012-08-11 18:53 +0100
          Re: hashCode Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-08-11 09:56 -0700
          Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 18:58 +0200
          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:40 -0400
        Re: hashCode rossum <rossum48@coldmail.com> - 2012-08-11 18:47 +0100
      Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:25 -0400
        Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 08:00 -0400
          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 09:49 -0400
    Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 15:33 +0200
      Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 15:34 +0200
      Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:34 -0700
        Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:37 -0700
        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:19 -0400
          Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 21:48 -0700
      Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 12:08 +0200
        Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 12:18 +0200
        Re: hashCode Lew <noone@lewscanon.com> - 2012-08-12 11:27 -0700
          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:11 -0400

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →

#18453

From	Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid>
Date	2012-08-31 00:52 +0200
Message-ID	<k1oqsq$p0u$1@dont-email.me>
In reply to	#18407

On 29/08/2012 20:49, Eric Sosman allegedly wrote:
> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>> On 8/28/12 5:02 PM, markspace wrote:
>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>
>>>> interface Hasher<Type> {
>>>>     int hash(Type t);
>>>
> The difficulty is that an external Hasher would have no access to
> private fields (...)

This.

-- 
DF.

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

#18460

From	Eric Sosman <esosman@ieee-dot-org.invalid>
Date	2012-08-30 21:43 -0400
Message-ID	<k1p4rh$im0$1@dont-email.me>
In reply to	#18453

On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>> On 8/28/12 5:02 PM, markspace wrote:
>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>>
>>>>> interface Hasher<Type> {
>>>>>      int hash(Type t);
>>>>
>> The difficulty is that an external Hasher would have no access to
>> private fields (...)
>
> This.

     ?

	package deal;
	public class ToBeHashed {
	    private int noGettersForMeThanks;
	    ...
	}

	package express;
	Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
	    public int hashCode(ToBeHashed obj) {
	        // How do you obtain the value of
	        // obj.noGettersForMeThanks
	        // if that would be useful?
	    }
	    ...
	}

As an example of why a hasher might want access to a strictly-private
field, I offered String: How could a Hasher<String> (outside String
itself) use String's private `hash' element?  (And before you say
"Give String a getHash() method," ponder what hashCode() does.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#18461

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2012-08-30 21:52 -0400
Message-ID	<504018cb$0$289$14726298@news.sunsite.dk>
In reply to	#18460

On 8/30/2012 9:43 PM, Eric Sosman wrote:
 > On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
 >> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
 >>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
 >>>> On 8/28/12 5:02 PM, markspace wrote:
 >>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
 >>>>>>
 >>>>>> interface Hasher<Type> {
 >>>>>>      int hash(Type t);
 >>>>>
 >>> The difficulty is that an external Hasher would have no access to
 >>> private fields (...)
 >>
 >> This.
 >
 >      ?
 >
 >      package deal;
 >      public class ToBeHashed {
 >          private int noGettersForMeThanks;
 >          ...
 >      }
 >
 >      package express;
 >      Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
 >          public int hashCode(ToBeHashed obj) {
 >              // How do you obtain the value of
 >              // obj.noGettersForMeThanks
 >              // if that would be useful?
 >          }
 >          ...
 >      }
 >
 > As an example of why a hasher might want access to a strictly-private
 > field, I offered String: How could a Hasher<String> (outside String
 > itself) use String's private `hash' element?  (And before you say
 > "Give String a getHash() method," ponder what hashCode() does.)

That is a very good point.

We could argue that equals should only depends on retrievable
information and so should hash.

But as you point out then there is the issue of caching
of hash values.

Arne

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

#18463

From	Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid>
Date	2012-08-31 04:18 +0200
Message-ID	<k1p6vk$s4p$1@dont-email.me>
In reply to	#18460

On 31/08/2012 03:43, Eric Sosman allegedly wrote:
> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>>> On 8/28/12 5:02 PM, markspace wrote:
>>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>>>
>>>>>> interface Hasher<Type> {
>>>>>>      int hash(Type t);
>>>>>
>>> The difficulty is that an external Hasher would have no access to
>>> private fields (...)
>>
>> This.
> 
>     ?
> 
>     package deal;
>     public class ToBeHashed {
>         private int noGettersForMeThanks;
>         ...
>     }
> 
>     package express;
>     Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
>         public int hashCode(ToBeHashed obj) {
>             // How do you obtain the value of
>             // obj.noGettersForMeThanks
>             // if that would be useful?
>         }
>         ...
>     }
> 
> As an example of why a hasher might want access to a strictly-private
> field, I offered String: How could a Hasher<String> (outside String
> itself) use String's private `hash' element?  (And before you say
> "Give String a getHash() method," ponder what hashCode() does.)
> 

Sorry for not being clear, Eric. I meant to emphasize how IMO that one
single point you mention is the decisive argument that settles the issue.

Imposing that classes should expose all information "relevant" (says
who??) to hashing is utter rubbish IMNSHO.

-- 
DF.

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

#18475

From	Jim Janney <jjanney@shell.xmission.com>
Date	2012-08-31 09:08 -0600
Message-ID	<ydnzk5brte4.fsf@shell.xmission.com>
In reply to	#18463

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:
>>> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>>>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>>>> On 8/28/12 5:02 PM, markspace wrote:
>>>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>>>>
>>>>>>> interface Hasher<Type> {
>>>>>>>      int hash(Type t);
>>>>>>
>>>> The difficulty is that an external Hasher would have no access to
>>>> private fields (...)
>>>
>>> This.
>> 
>>     ?
>> 
>>     package deal;
>>     public class ToBeHashed {
>>         private int noGettersForMeThanks;
>>         ...
>>     }
>> 
>>     package express;
>>     Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
>>         public int hashCode(ToBeHashed obj) {
>>             // How do you obtain the value of
>>             // obj.noGettersForMeThanks
>>             // if that would be useful?
>>         }
>>         ...
>>     }
>> 
>> As an example of why a hasher might want access to a strictly-private
>> field, I offered String: How could a Hasher<String> (outside String
>> itself) use String's private `hash' element?  (And before you say
>> "Give String a getHash() method," ponder what hashCode() does.)
>> 
>
> Sorry for not being clear, Eric. I meant to emphasize how IMO that one
> single point you mention is the decisive argument that settles the issue.
>
> 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.
Relying on non-public information in the comparison method means
allowing two objects to compare non-equal even though there is no way,
using public information, to distinguish between them.  I can honestly
say I've never done that or felt a need to do that.

-- 
Jim Janney

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

#18476

From	Eric Sosman <esosman@ieee-dot-org.invalid>
Date	2012-08-31 11:38 -0400
Message-ID	<k1qlpa$kjv$1@dont-email.me>
In reply to	#18475

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.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#18477

From	Robert Klemme <shortcutter@googlemail.com>
Date	2012-08-31 17:55 +0200
Message-ID	<aac53sFoqmU1@mid.individual.net>
In reply to	#18476

On 31.08.2012 17:38, Eric Sosman wrote:
> 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.

Well, Jim's wording may not be correct to the last bit but the message 
is still true: String's hash member just caches the hash code derived 
from the characters of the String.  And obviously equals() must compare 
the characters.  So basically both recur to the same underlying data.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

#18478

From	Jim Janney <jjanney@shell.xmission.com>
Date	2012-08-31 09:56 -0600
Message-ID	<ydnvcfzrr5r.fsf@shell.xmission.com>
In reply to	#18476

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.

-- 
Jim Janney

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

#18482

From	Eric Sosman <esosman@ieee-dot-org.invalid>
Date	2012-08-31 14:32 -0400
Message-ID	<k1qvvt$nvb$1@dont-email.me>
In reply to	#18478

On 8/31/2012 11:56 AM, Jim Janney wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>[...]
>>> 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.

     Right.  Except hashCode() can arrange to compute the value
just once, while an external Hasher without access to the private
field would need to recompute it every single time.  I never said
a Hasher could not compute a perfectly good hash code (for a sane
class, at any rate), just that it would have to forego benefits
that are available to an internal hashCode() method.

     Are those benefits worth while?  Sometimes yes, sometimes no.
Sun apparently believed that they were in fact worth while in the
case of java.lang.String (indeed, Bloch says String's hashCode()
received a lot of attention and went through multiple generations).
If you think caching String's hash is not worth the effort, I
encourage you to experiment with a variant rt.jar that omits the
cache, run some timings, and report the results.

     To the other issue, about whether HashMap et al. should
have a constructor taking an externally-supplied Hasher as an
alternative to using the key's own hashCode() -- well, HashMap
is not a final class.  Have at it!

     (Nor, by the way, do I deny the potential utility of such
a hashed map.  It could, for example, have been used to get
around the inadequacies of String.hashCode() in early Java ...)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#18486

From	Jim Janney <jjanney@shell.xmission.com>
Date	2012-08-31 14:38 -0600
Message-ID	<ydnr4qmssp7.fsf@shell.xmission.com>
In reply to	#18482

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 8/31/2012 11:56 AM, Jim Janney wrote:
>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>[...]
>>>> 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.
>
>     Right.  Except hashCode() can arrange to compute the value
> just once, while an external Hasher without access to the private
> field would need to recompute it every single time.  I never said
> a Hasher could not compute a perfectly good hash code (for a sane
> class, at any rate), just that it would have to forego benefits
> that are available to an internal hashCode() method.
>
>     Are those benefits worth while?  Sometimes yes, sometimes no.
> Sun apparently believed that they were in fact worth while in the
> case of java.lang.String (indeed, Bloch says String's hashCode()
> received a lot of attention and went through multiple generations).
> If you think caching String's hash is not worth the effort, I
> encourage you to experiment with a variant rt.jar that omits the
> cache, run some timings, and report the results.

I certainly think that the performance gained from caching matters.  But
your objection is without substance: 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 String is very much an unusual case: it's final, immutable, and
frequently used as a hash key.  Not many other classes will fall into
that category.

-- 
Jim Janney

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

#18489

From	Lew <lewbloch@gmail.com>
Date	2012-08-31 15:33 -0700
Message-ID	<c230ca57-ae64-4a1c-8799-52bb2a7641e1@googlegroups.com>
In reply to	#18478

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

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

#18490

From	Jim Janney <jjanney@shell.xmission.com>
Date	2012-08-31 16:41 -0600
Message-ID	<ydnipbysmzv.fsf@shell.xmission.com>
In reply to	#18489

Lew <lewbloch@gmail.com> writes:

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

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.

-- 
Jim Janney

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

#18491

From	Lew <lewbloch@gmail.com>
Date	2012-08-31 16:26 -0700
Message-ID	<cac34249-3fbb-4ddf-b1fa-903375e51c2e@googlegroups.com>
In reply to	#18490

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

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

#18511

From	Jim Janney <jjanney@shell.xmission.com>
Date	2012-09-02 11:54 -0600
Message-ID	<ydnehmks428.fsf@shell.xmission.com>
In reply to	#18491

Lew <lewbloch@gmail.com> writes:

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

Nothing in the hypothetical design prevents String, or any other class,
from defining a hashCode method, or multiple methods, with access to
private data or native code.  Objections on this basis are therefore
without basis.  I'm sorry if you find this confusing, but it's really
very simple.

It's also true that the majority of hash functions should depend only
on publically available data.  This is not "rubbish" but a direct
consequence of how hashing works: objects that compare equal must hash
to the same value.  In a small number of cases, using a private member
to cache the result of the hash calculation turns out, on average, to
be better than not cacheing it.  This takes us back to the previous
point.

As you point out, the current design is not all that bad, but it's also
limiting and error prone.  Limiting because a class can only have one
hash function when several might be useful: for instance, String has
equalsIgnoreCase but no hashCodeIgnoreCase.  If you want to hash by
object identity for a class that overrides equals() and hashCode(), you
have to use a completely different implementation of the standard hash
map.  Error prone because it takes concerns that should be kept together
(hashing is a concern of the map, not the object being hashed) and
divides them into otherwise unrelated classes.  If you want to override
equals() for a class, how do you know where to look for hash maps that
might be affected?

-- 
Jim Janney

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

#18516

From	Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid>
Date	2012-09-03 00:47 +0200
Message-ID	<k20no1$1fb$1@dont-email.me>
In reply to	#18511

On 02/09/2012 19:54, Jim Janney allegedly wrote:
> It's also true that the majority of hash functions should depend only
> on publically available data.  This is not "rubbish" 

Indeed, *that* is not. It's merely questionable.

Mandating that *every* class conform to this scheme, however, is rubbish.

All this discussion is essentially an invitation to throw access control
to the four winds.

-- 
DF.

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

#18525

From	Jim Janney <jjanney@shell.xmission.com>
Date	2012-09-03 21:44 -0600
Message-ID	<ydna9x6sb93.fsf@shell.xmission.com>
In reply to	#18516

Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> writes:

> On 02/09/2012 19:54, Jim Janney allegedly wrote:
>> It's also true that the majority of hash functions should depend only
>> on publically available data.  This is not "rubbish" 
>
> Indeed, *that* is not. It's merely questionable.
>
> Mandating that *every* class conform to this scheme, however, is rubbish.
>
> All this discussion is essentially an invitation to throw access control
> to the four winds.

I was going to comment on this, but when I went to pick up another
"once again" they were fresh out of them... told me some crazy story
about a guy coming through in a big hurry and cleaning out the entire
stock.  So you'll just have to imagine what I might have said :-)

-- 
Jim Janney

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

#18474

From	Jim Janney <jjanney@shell.xmission.com>
Date	2012-08-31 09:08 -0600
Message-ID	<ydn1uint7z3.fsf@shell.xmission.com>
In reply to	#18460

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>>> On 8/28/12 5:02 PM, markspace wrote:
>>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>>>
>>>>>> interface Hasher<Type> {
>>>>>>      int hash(Type t);
>>>>>
>>> The difficulty is that an external Hasher would have no access to
>>> private fields (...)
>>
>> This.
>
>     ?
>
> 	package deal;
> 	public class ToBeHashed {
> 	    private int noGettersForMeThanks;
> 	    ...
> 	}
>
> 	package express;
> 	Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
> 	    public int hashCode(ToBeHashed obj) {
> 	        // How do you obtain the value of
> 	        // obj.noGettersForMeThanks
> 	        // if that would be useful?
> 	    }
> 	    ...
> 	}
>
> As an example of why a hasher might want access to a strictly-private
> field, I offered String: How could a Hasher<String> (outside String
> itself) use String's private `hash' element?  (And before you say
> "Give String a getHash() method," ponder what hashCode() does.)

I have, and I don't see a problem.  String can define hashCode(), and
hashCodeIgnoreCase(), and hashCode(Locale), if those turn out to be
useful things to do for that particular class (String is an exceptional
class in several ways).  The objection is to building hashCode() into
the Object hierarchy and hard-coding its use in HashMap.  A separate
interface would allow more flexibility.

-- 
Jim Janney

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

#18479

From	Robert Klemme <shortcutter@googlemail.com>
Date	2012-08-31 17:58 +0200
Message-ID	<aac59uFq4tU1@mid.individual.net>
In reply to	#18474

On 31.08.2012 17:08, Jim Janney wrote:
> The objection is to building hashCode() into
> the Object hierarchy and hard-coding its use in HashMap.  A separate
> interface would allow more flexibility.

Absolutely!  And if we add another method we don't even need 
IdentityHashMap any more.  See my example here:

http://blazyog.blogspot.de/2012/08/better-approach-to-make-hashing-in-java.html

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

#18408

From	markspace <-@.>
Date	2012-08-29 11:51 -0700
Message-ID	<k1loc9$967$1@dont-email.me>
In reply to	#18401

On 8/29/2012 11:06 AM, Daniel Pitts wrote:

> Map<MyKey, MyValue> map=new HashMap<MyKey,MyValue>(new MyKeyHasher());

> Does that make more sense?

I see.  You're changing the specification arbitrarily to fit your needs. 
  That wasn't what I had in mind.  Sure, if you just assume you can do 
what you like you can re-write library code, but the idea was to hash 
Object, without having to supply a "MyKeyHasher".

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

#18414

From	Daniel Pitts <newsgroup.nospam@virtualinfinity.net>
Date	2012-08-29 13:28 -0700
Message-ID	<5Yu%r.362$1M4.148@newsfe19.iad>
In reply to	#18408

On 8/29/12 11:51 AM, markspace wrote:
> On 8/29/2012 11:06 AM, Daniel Pitts wrote:
>
>> Map<MyKey, MyValue> map=new HashMap<MyKey,MyValue>(new MyKeyHasher());
>
>> Does that make more sense?
>
>
> I see.  You're changing the specification arbitrarily to fit your needs.
>   That wasn't what I had in mind.  Sure, if you just assume you can do
> what you like you can re-write library code, but the idea was to hash
> Object, without having to supply a "MyKeyHasher".

The point is that hashing "Object" isn't entirely sensible in most 
situations.  Granted, there are some situation where Identity is what 
you really want to key off of, but they are far fewer than a "value" 
comparison.  On top of that, I've often needed two different ways to 
"compare" object equality, depending on the context of that comparison. 
The Hasher concept would decouple the comparison from the user of the 
hash, and potentially from the hashable object.

Now, just like the Comparable interface exists, a Hashable interface 
could also exist, for classes which provide a "default" comparison.

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

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →

csiph-web

hashCode

Contents

#18453

#18460

#18461

#18463

#18475

#18476

#18477

#18478

#18482

#18486

#18489

#18490

#18491

#18511

#18516

#18525

#18474

#18479

#18408

#18414