From: gwtmp01@...
Date: 2006-06-28T06:07:05+09:00
Subject: Re: Ruby and Java equality usage


On Jun 27, 2006, at 2:59 PM, Molitor, Stephen L wrote:
>> Why doesn't the default implementation of Object#eql? just use #==
>>  internally?
>
> Good question!  Or to put it another way why do we need separate ==  
> and
> eql? methods?  The only rationale I can think of is to completely
> separate the hash related methods (eql? and hash) from ==.

Here is my take on the equality methods:

a.equal?(b) 	# identity: do a and b reference the same object?
a.eql?(b)	# representation: do a and b reference objects with the  
same value and same representation?
a.==(b)		# equivalence: do a and b reference objects with the same  
value regardless of representation?
g.===(b)	# membership: does b belong to the 'group' g?


3.eql?(3.0)       is false because two different representations are  
being compared
3 == 3.0          is true because the same value is represented by  
both objects
0 == Complex(0,0) is true, same value, different representation

String === "s"  is true because "s" is member of the collection of  
all Strings
0..10 === 4     is true because 4 is a 'member' of the range
/[ab]/ === 'a'  is true because a is a 'member' of the strings  
matched by the re

There is also include? which is defined for quite a few classes and  
which is very
similar to === in many cases.

Don't forget the '=~' operator which is like === but returns an index  
within the
group, which is reminiscent of Array#index, for example.

It seems to me that with a little work, ===, =~, index, and include?  
semantics could be
made a bit more uniform.  For example:

	s = Set.new [1,2,3]
	s.include? 1		# true
	s === 1			# false, why not behave like include? here

	a = [:apple, :banana, :cherry]
	a.index(:banana)	# 1
	a =~ :banana		# false  (why not return 1?)

	a.include?(:banana)	# true
	a === :banana		# false  (why not return true?)

I suspect it might be difficult to avoid breaking existing code if  
these changes
were made.

Gary Wright