On 12/03/2010 06:28 PM, Rick DeNatale wrote:
> On Thu, Dec 2, 2010 at 5:35 PM, Robert Klemme
> <shortcutter / googlemail.com>  wrote:
>> On 12/02/2010 10:46 PM, Yossef Mendelssohn wrote:
>>
>>> Although I still think what I was trying to point out is something to
>>> consider, that simply delegating #hash to an internal element isn't
>>> all that good because on some level it makes them the same.
>>
>> Ultimately all hash values are derived from member hash values.  The key
>> point - and I believe this is what you want to stress - is _how_ values are
>> derived.  The methodology applied should strive to yield different hash
>> values for things that are considered non equivalent.  For example, hash
>> value of an Array or list implementation should somehow consider position of
>> elements in order to not return the same hash for two collections which only
>> differ in ordering.  We can see that Array#hash obeys this:
>>
>> irb(main):001:0>  [1,2].hash
>> =>  11
>> irb(main):002:0>  [2,1].hash
>> =>  1
>>
>> On the other hand, since Set conceptually is agnostic of position different
>> ordering of elements should not create different hash codes:
>>
>> irb(main):001:0>  require 'set'
>> =>  true
>> irb(main):002:0>  s1 = [1,2].to_set
>> =>  #<Set: {1, 2}>
>> irb(main):003:0>  s2 = [2,1].to_set
>> =>  #<Set: {2, 1}>
>> irb(main):004:0>  s1.hash
>> =>  14
>> irb(main):005:0>  s2.hash
>> =>  14
>> irb(main):006:0>  s1 == s2
>> =>  true
>
> Note that Set, like hash depends on that implication relationship
> between #hash and #eql?

This is a different story: I was talking about how Set calculates its 
hash code from members.  You are talking about how Set determines member 
equivalence and especially what role the implementation of #hash of the 
_members_ plays in this.

Kind regards

	robert