From: Robert Klemme <shortcutter@...>
Date: 2006-06-27T02:20:53+09:00
Subject: Re: Ruby and Java equality usage

2006/6/26, Robert Dober <robert.dober@gmail.com>:
> Are you sure you read the page correctly?

Pretty sure.

> I copy paste:
<snip/>

> Now unless this is wrong, one can conclude that
> * #equal? shall not be redefined,

Agreed.

> * #eql? should not be redefined, unless 1's knowing what one's doing (not 4
> me ;=)

Disagreed.  If you redefine == then you should usually redefine eql?
as well and with similar semantics:

"[Method ==] Typically, this method is overridden in descendent
classes to provide class-specific meaning."

"For objects of class Object, eql? is synonymous with ==. Subclasses
normally continue this tradition, but there are exceptions."

So for subclasses == and eql? are usually synonymous even if == is redefined.

> but
> * #== can be redefined freely.

"Freely" is a bit too much freedom here for my taste.  Of course we
can implement all these methods in any way we like to, but for a
typical class == and eql? should reflect equivalence of objects
(you're probably mean the same, I'd just like to make the point in
order to help with the engraving :-)). And this in turn usually
depends on instance variables.  So the behavior of Struct.new (which
defines a new class with a set of attributes) is pretty much the way
to go *usually*.  There are other cases where only some attributes
should be used or even the default Object behavior retained but the
rule of thumb should be, if you implement ==, then also implement eql?
(for example by making it an alias) and hash and have all compare
based on member variables / attributes / observable state.

> Personally I find this situation a bit odd.  I'd prefer a single
> > equivalence relation per class not two.
>
> Although I do not feel the same that seems a normal concern, as I pointed
> out to the OP.
> Honestly I think it depends on the programming culture we are coming from
> and when
> in our mind these are synonyms we are likely to get bitten by that kind of
> code.

At the moment I'm not so sure whether culture is the background.  I
tend to think that there's a more fundamental issue: having a single
equivalence relation defined on instances of a class seems to make
things easier in several areas and I believe that it rather reduces
programming errors.

> I can only offer you my sympathy not my agreement.

Although sympathy is better than nothing I'd rather convince you. :-)

> But if we discuss this long enough it will become completely engraved in our
> minds in we will be aware of it even if we do not like it ;)

I'm the last one not to help engrave something like this in
everybody's minds so I'll happily continue this thread. :-)

Kind regards

robert

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