2006/6/27, Robert Dober <robert.dober / gmail.com>:
> On 6/27/06, Alexandru Popescu <the.mindstorm.mailinglist / gmail.com> wrote:

<snip/>

> Still, I have formulated a conclusion in the previous post, and that
> > will be the one that will go to the entry for update:
> >
> > #eql? is just syntactic sugar of #==, needed for objects used as keys
> > in hashes (because hash implementation doesn't like to use #==, but
> > only #eql?). If your class needs to override #==, than just delegate
> > #eql? implementation to #==.
>
> Please be aware that this is in contradiction to the official documentation.

Can you please state how exactly this contradicts the official
documentation?  I know you stated that before but somehow I miss your
answer to my question in an earlier post.

I don't think there is a contradiction, delegating eql? to == is a
valid way to achieve that both are implemented the same - with the
added benefit that this is maintained for subclasses also as long as
they do not decide to override eql?.

> Maybe the doc is wrong but nobody has claimed that so far.
> It will also break Hash lookup unless the reimplementation of #== is very
> careful!

What do you mean by "careful"?  Of course, =='s implementation should
be reasonable but careful?  What additional caveats do you see?

> ( I will try to demonstrate this as soon as I have a little time )

I'm looking forward to that.

> Hopefully everybody is backing me up on this one even if they think that is
> how it *should* be. Right now it is *not* how it is.

I'm not sure whether we read the same documentation - I get the
feeling that we interpret the same text in different ways.

Kind regards

robert

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