Mark Wilson
10/1/2003 6:32:00 PM
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