From: Mark Wilson <mwilson13@...>
Date: 2003-10-02T03:31:48+09:00
Subject: Re: Making == symmetric?


On Wednesday, October 1, 2003, at 12:21 PM, Nathan Weston wrote:

> [snip]
>> I think you're mixing up variables and values. d refers to a D object
>> instantiated with a Foo object. f refers to the Foo object used to
>> instantiate the D object. The D object has an == method that checks 
>> its
>> value and compares it to the given value. When invoked by d==f, the D
>> object sees that its value is the Foo object and sees that f refers to
>> the Foo object and determines that they are the same object. In other
>> words the D object is the functional equivalent of an assignment to a
>> primitive variable.
>
> [snip]
>
> I understand how and why things work the way they do in ruby -- I just
> happen to think that way is wrong.
>
> The issue in the above example is not whether f and d are equal (in
> the code I am working on now, it would be convenient if they were, but
> that's beside the point). The issue is that f and d (or rather, the
> objects they refer to), don't agree on whether they are equal. I think
> that is a bad thing.
>
> Essentially what I am looking for is a way for an object, when asked
> if it is equal to some other object, to answer "I don't know".
>
> [snip]

First off, thank you for some fascinating ideas and questions. I happen 
to like Sean O'Dell's views further down in this thread.

I don't know enough to have firm views on the topic, but I do have a 
couple of thoughts.

1. Sometimes, one will want two objects of the same class and with the 
same attributes to return false when the == operator is applied. For 
example, a pool of identical server objects should not be considered 
equal to each other.

2. In general, two objects of different classes should return false 
when the == operator is applied to either of them, unless the classes 
differ only in name. I think whether this behavior is varied in 
specific cases would depend on how the class is meant to be used.

I would definitely like to hear more on this topic from others.

Regards,

Mark