Alexandru Popescu wrote:
> Rober, thanks and thanks. I think you are right. I am a little sad
> because I have hoped to find a good answer to this, so that others
> will have a good reference for this subject and will not have to pass
> through phylosophical times as I had when reading for the first time
> about equality in Ruby.
> 
> Unfortunately, even if I play with Ruby for almost 2 years, I don't
> consider that I have enough knowledge to come up with authoritative
> posts, so this is the reason for my mildy posts. If this would have
> been on a Java subject, things would have been completely different
> ;-), but here I just try to keep myself "low profile" and extract as
> information as possible.
> 
> Still, I have formulated a conclusion in the previous post, and that
> will be the one that will go to the entry for update:
> 
> #eql? is just syntactic sugar of #==, needed for objects used as keys
> in hashes (because hash implementation doesn't like to use #==, but
> only #eql?). If your class needs to override #==, than just delegate
> #eql? implementation to #==.
Just to weigh in here on how I think of it, without this necessarily 
being representative of any section of reality:  #eql? is used for 
value-and-type equality, where #== is used for value-equivalence.  Thus 
2.0 == 2 #=> true, 2.eql? 2.0 #=> false.  For most types, they'll be 
identical, because 98 classes out of 100 simply don't have a 
value-equivalence relationship.

Of course, I could be very, very wrong about this, partially because the 
only example I can think of off the top of my head where this is the 
case is Fixnum == Float, and partially because it implies a certain 
flexibility to the strongly-typed approach which seems quite 
uncharacteristic.

-- 
Alex