> On Oct 9, 2015, at 7:51 AM, Henrik Johansen <henrik.s.johan...@veloxit.no>
> wrote:
>
>
>>> On 09 Oct 2015, at 4:33 , Esteban Lorenzano <esteba...@gmail.com> wrote:
>>>
>>>
>>> On 09 Oct 2015, at 16:21, Gabriel Cotelli <g.cote...@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.
