From: Jacob Fugal <lukfugl@...>
Date: 2006-06-28T01:32:14+09:00
Subject: Re: Ruby and Java equality usage

On 6/27/06, ts <decoux@moulon.inra.fr> wrote:
> >>>>> "J" == Jacob Fugal <lukfugl@gmail.com> writes:
>
> J> The one question I do have regarding this is why isn't the default
> J> implementation of Object#eql? as an alias to Object#==? The
> J> documentation makes it clear that that's the intended behavior, and
> J> the common behavior for descendants of Object as well. It seems odd
> J> that it's not then codified as an alias. It seems redundant that we
> J> have to always remember to alias #eql? if we override #==; why can't
> J> it be the default to already be an alias?
>
>  becuase this will change nothing
<snip alias example>

Ah, good point. And after reading that, it got me thinking about how
the same question could be asked about why the default implementation
isn't something like:

  class Object
    def eql?(other)
      self == other
    end
  end

And thinking about that, I realized why. As Daniel Martin mentioned,
the implication:

  a.eql?(b) implies a.hash == b.hash

Should always be maintained. Now, if I recall correctly, the default
Object behavior is:

  * hash returns the object_id
  * equal? compares object_ids (this should never be overridden)
  * == is implemented in terms of equal?
  * eql? also compares object_ids (maybe also implemented in terms of eql?)

So by default, == and eql? are synonymous. But if we override ==, and
eql? were to implicitly follow, but we didn't also override hash, the
above implication would no longer hold. Chaos ensues.

So the primary reason eql? is separate from == is that eql? needs to
be sure to follow hash. So now my question is: why isn't the default
implementation of eql? to compare hash instead of object_id? Then we
can override hash in cases where we want to, and not need to worry
about eql? unless we really need to...

Jacob Fugal