From: Aaron Patterson <aaron@...>
Date: 2007-11-25T03:52:47+09:00
Subject: Re: Hashes, Sets, and eql?

On Sat, Nov 24, 2007 at 11:35:05PM +0900, Phrogz wrote:
> On Nov 24, 4:35 am, MonkeeSage <MonkeeS...@gmail.com> wrote:
> > On Nov 24, 1:25 am, Aaron Patterson <aa...@tenderlovemaking.com>
> > wrote:
> >
> > > Nope.  I don't want a shallow comparison.  I need to use my sets as hash
> > > keys, so I need .eql? and .hash.  Set calls eql? on the internal hash object.
> >
> > And eql? implies a.hash == b.hash. That is an object comparison, since
> > Object#hash gives a unique value for every object like Object#id. What
> > you need is shallow comparison of values rather than objects: a == b.
> > I'm not sure how to easily make Hash do that.
> 
> Not always true:
> 
> irb(main):001:0> a1 = [:a,1,'foo']
> => [:a, 1, "foo"]
> irb(main):002:0> a2 = [:a,1,'foo']
> => [:a, 1, "foo"]
> irb(main):003:0> a1.hash
> => 876036089
> irb(main):004:0> a2.hash
> => 876036089

Yes.  I guess my point is this: given the behavior of eql? and hash on
Array, would you expect the same behavior from Set?  I did, and found it
surprising when they didn't behave the same way.

Now, I can understand an argument against having the same behavior since Sets
are unordered.  But if that is the case, then why even implement .eql?
and .hash on the Set class?  Since those methods are implemented on Set,
it leads me to believe that the original intent was for .eql? and .hash
to behave the same way as on Array.

-- 
Aaron Patterson
http://tenderlovemaking.com/