On Oct 9, 2015, at 7:51 AM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:


On 09 Oct 2015, at 4:33 , Esteban Lorenzano <estebanlm@gmail.com> wrote:


On 09 Oct 2015, at 16:21, Gabriel Cotelli <g.cotelli@gmail.com> wrote:

If the collection implements = using the objects it holds then you need to consider at least some of them in the hash calculation. I can't conceive a hash calculation for this case independent of the contents (well,  just hardcode a number but this will lead to always collide if used as a key in a hashed collection).

it is not :)


I'm with Levente here, I think the hash implementation is reasonable. And I wouldn't use a mutable object as key in a hashed collection.

no idea��� I���m not using it, just arrive to that method random and I cannot understand it. 
I still believe is wrong. 
It's not.

Either Dictionary >> #= or IdentityDictionary >> #species in Pharo *is* broken though.

dic1 := Dictionary newFrom:{1 -> 4}.
dic2 := IdentityDictionary newFrom: dic1 associations .

dic1 = dic2     true
dic1 hash = dic2 hash false

Cheers,
Henry

+1.  Henry is right.  Esteban, given
    #(1 2 3) = #(1 2 3)
and
    #(1 2 3) ~= #(1 2 3 4)
we require that
    #(1 2 3) hash = #(1 2 3) hash
and would like that
#(1 2 3) hash ~= #(1 2 3 4) hash

Now it's too much for me to type in my phone but exactly the same should be true of dictionaries.  And given that a Dictionary with eg key/value pairs 1->a 2->b 3->c can have 4->d added to it it implies that if the hash function is good it will change when 4->d is added.  And as others have said if you want a hash that doesn't change there is the identityHash and identity collections for that very purpose.