From: Rick DeNatale <rick.denatale@...>
Date: 2007-10-19T03:07:38+09:00
Subject: Re: equal? versus eql? versus == versus === verus <=>

On 10/18/07, Stefan Rusterholz <apeiros@gmx.net> wrote:
> Rick Denatale wrote:
> >   def hash
> >     to_a.sort.hash
> >   end
>
> This requires the hash key and value to implement <=> which will not be
> always the case and thus breaks.

Correct, depending on the individual hash. On the other hand this is
yet another aspect of the subtle differences between the 'type' of an
object and its class, and I don't think that such things are probably
unavoidable is such an evil thing:

http://talklikeaduck.denhaven2.com/articles/2007/10/17/you-cant-judge-a-book-some-mental-traps-in-learning-ruby

> >   def hash
> >     1
> >   end
> > ...
> > but I'm not sure that mapping the hash value to a
> > constant is a good idea.
>
> I'm sure it is not. That way every Hash as key is stored in the same
> bucket, essentially making it no different from an Array in the way keys
> are looked up (only advantage is, that you don't have the method call
> overhead you'd have with an Array solution).

Well not exactly, it means that there will always be a collision,
followed by searching in the hash.

I was actually subtly reinforcing the point that performance
considerations might well have driven the decision to make Hash#eql?
be an alias for equal?  To be fair, my naive constant hash could be
improved by using some inexpensive quality which did partitioned
hashes into a greater number of equivalence classes, for example
perhaps:
class Hash
  def hash
       length
  end
end

Although this would be been pretty ineffective in Phrogz' use-case

It might be of interest to note that Smalltalk has both a Dictionary
(which is pretty much equivalent to Ruby's Hash) and an
IdentityDictionary which uses object-identity instead of equality to
differentiate keys.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/