Mathieu Bouchard wrote:

>> I think that we currently have too many equality methods with similar 
>> names:
>> I think that equal?() is rarely used and that removing it completely 
>> would make sense -- after all  a.id == b.id  is not much longer than 
>> a.equal?(b).
> 
> I would agree, except for backwards-compatibility issues.

I think backwards-compatibility is not too much of a problem -- we don't 
need to remove this method immediately. Rather, there could be a warning 
period where using it emits a warning that it is now considered obsolete.

>> Renaming it might also be an option -- I think Object#identical?() 
>> would be a good name.
> 
> also Object#same? would be a better and shorter name, but I don't really 
> care because I'd rather write it a.id==b.id and then I rarely ever need 
> to even do that.

I'm not sure about same?() -- it does have the same meaning, but I think 
it might be too close to "same value". I think identical?() is more 
explicit. (It has the "identity" bit right inside the method name.)

I agree in that we might not even need a name for comparing object ids, 
however.

>> I would also like to see eql?() renamed, but I'm not sure about the 
>> name and it also seems to be used much more which would make a change 
>> more troublesome. Perhaps hash_equal?() would be a better name.
> 
> it would be troublesome to do that kind of thing because #eql? and #hash 
> are the "hashable" interface which gets redefined by user-defined code, 
> and then renaming is much trickier (aliases are pretty wrong in that 
> case). So I don't agree with this part of the proposal.

Yup, that is pretty much my concerns as well. There's also a lot of 
cases where this is used and forcing that much effort on everybody just 
to clear up terminology a bit might not be worth it. But just thinking 
about a better name does not mean that we have to start using it. We 
could still switch over to it if there was a good opportunity for doing so.