elbows
10/1/2003 4:07:00 PM
Mark Wilson <mwilson13@cox.net> wrote in message news:<3AA52722-F3B5-11D7-951C-000393876156@cox.net>...
> Those more knowledgeable than me should correct what I've written below
> if it's wrong.
>
> On Tuesday, September 30, 2003, at 07:19 PM, Nathan Weston wrote:
>
> > It has always bothered me that == is not symmetric in ruby:
> > a == b is shorthand for a.==(b), while b == a is shorthand for
> > b.==(a), and a and b might not agree on whether they are equal.
>
> I think it is symmetric so long as you bear in mind that the method
> belongs to the object and not to the variable that refers to the
> object. See below.
If == is symmetric, then (a == b) if and only if (b == a). In ruby,
this is not always the case, which can be very confusing.
I'm not sure what this has to do with the method belonging to the
object rather than the variable.
>
> > [snip]
>
[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".
>
>
> > I ran into a similar problem trying to implement perl6-style
> > junctions: you end up with any(1,2,3) == 1 being true, but 1 ==
> > any(1,2,3) being false.
>
> I didn't follow the above point. There was an earlier discussion on the
> list about perl6-style junctions that might be helpful.
>
Admittedly I didn't elaborate on that point too much. I went back and
read the earlier discussion (which I actually started), and here is
the exact problem:
Suppose we have a method any(*args), which creates a junction object
of its arguments.
Then any("1", "2", "3") == "1" evaluates to true (which is correct).
However, "1" == any("1", "2", "3") evaluates to false (which is not
correct).
The problem is that String doesn't know about the Junction class, and
therefore assumes it is not equal to any instances of it. (Maybe it
looks for a to_str method first, or somesuch -- I don't know the
implementation details exactly). There is no way around this, no
matter how you implement Junction, because in the second case the
comparison is don exclusively by String -- none of Junction's methods
are ever called.
Under my solution, a comparison between a "1" and any("1", "2", "3"),
would first ask "1" if it knows how to compare itself to the junction.
The answer would be "no", since the string class doesn't know anything
about junctions. However, the junction does know how to compare itself
to a string, so the junction's comparison method would be called
(regardless of which side of the == the junction is on).
Nathan