2006/6/26, Robert Dober <robert.dober / gmail.com>:
> On 6/26/06, Alexandru Popescu <the.mindstorm.mailinglist / gmail.com> wrote:

> > However, I feel I have missed to explain correctly why eql? and ==
> > are both needed (and I've been reading through Ruby books and searched
> > the ruby mailing list). Maybe somebody can clarify it and give a
> > better example. I will be happy to update the entry to reflect the
> > "new" knowledge.
>
> I am surprised you did not find this reference, possibly I missed a point in
> your mail
> http://www.ruby-doc.org/core/classes/Object.html#M001416
> if I interpret it correctly
>
> == is supposed to be redefined in classes in order to reflect identity on an
> "application" level.
> equal? shall not be redefined in order to be available for object identity,
> something like
>           a.equal?(b) iff a.object_id == b.object_id
> eql? is used for Hash entry comparison and is not redefined most of the time

I don't fully agree to your point.  Basically == and eql? are meant to
implement object equivalence.  So if you implement == you should be
implementing eql? and hash, too.  And usually == and eql? should
behave the same.  The page you mention quotes "For objects of class
Object, eql? is synonymous with ==. Subclasses normally continue this
tradition, but there are exceptions.". Numbers make a suble difference
here:

>> 1 == 1.0
=> true
>> 1.eql? 1.0
=> false

Personally I find this situation a bit odd.  I'd prefer a single
equivalence relation per class not two.

Kind regards

robert

-- 
Have a look: http://www.flickr.com/photos/fussel-foto/