Comparable glitch/aspect?

D

David Dyer-Bennet

I had a class that included Comparable and defined <=>, I think
correctly, where a check for != between objects was returning false
when it should have returned true. Reading carefully, Comparable says
it defines a bunch of comparison operators, but *not* !=. Ruby
documentation says that != comes automatically from ==, though.
Anyway, I changed the class to get rid of comparable and define ==
(I'm at the playing level, but in fact inequality comparisons aren't
important for this class anyway), and things started working as I
expected.

Are there weirdnesses to how these things work that I'm missing? Or
is it most likely that I just had something simple wrong and didn't
realize it, and managed to accidentally fix it while thrashing around
(these things happen!)? Should my <=> + Comparable implementation have
provided a !=?

(I'm coming to Ruby from almost 4 decades of programming experience,
and considerable C++ and object-oriented perl and PHP work, which no
doubt biases the particular kinds of newbie mistakes I will commit.)
 
T

Tim Hunter

David said:
I had a class that included Comparable and defined <=>, I think
correctly, where a check for != between objects was returning false
when it should have returned true. Reading carefully, Comparable says
it defines a bunch of comparison operators, but *not* !=. Ruby
documentation says that != comes automatically from ==, though.
Anyway, I changed the class to get rid of comparable and define ==
(I'm at the playing level, but in fact inequality comparisons aren't
important for this class anyway), and things started working as I
expected.

Are there weirdnesses to how these things work that I'm missing? Or
is it most likely that I just had something simple wrong and didn't
realize it, and managed to accidentally fix it while thrashing around
(these things happen!)? Should my <=> + Comparable implementation have
provided a !=?

(I'm coming to Ruby from almost 4 decades of programming experience,
and considerable C++ and object-oriented perl and PHP work, which no
doubt biases the particular kinds of newbie mistakes I will commit.)

I don't have the Ruby source code in front of me but I'm pretty sure
that Comparable says that == is true when <=> returns 0.

module Comparable
def ==(other)
return (self <=> other) == 0
end
end

So != is true when <=> returns either -1 or 1.

Is it possible you're expecting 0 to be false? In Ruby everything is
true except false and nil.
 
D

David Dyer-Bennet

Tim Hunter said:
I don't have the Ruby source code in front of me but I'm pretty sure
that Comparable says that == is true when <=> returns 0.

module Comparable
def ==(other)
return (self <=> other) == 0
end
end

So != is true when <=> returns either -1 or 1.

Is it possible you're expecting 0 to be false? In Ruby everything is
true except false and nil.

Hmmm; I thought originally when you suggested it that that must have
been the problem, but actually I don't think so. I was thinking
wrong, but not in places where it mattered then, I don't think. My
<=> implementation returned either the value of a <=> between strings,
or else a literal 0 if no difference could be found -- but <=> is -1,
0, 1, so that's correct.

I found this while working on unit tests for the thing, so at this
point I not only have something that works, but something that will
tell me if it stops working in the future, so we'll see if it comes
back.

It's useful to be reminded about the 0 not being false thing, even if
that wasn't the cause of the specific problem.
 
D

David Dyer-Bennet

David Dyer-Bennet said:
Hmmm; I thought originally when you suggested it that that must have
been the problem, but actually I don't think so. I was thinking
wrong, but not in places where it mattered then, I don't think. My
<=> implementation returned either the value of a <=> between strings,
or else a literal 0 if no difference could be found -- but <=> is -1,
0, 1, so that's correct.

Ah! And now I see where I was expecting an integer to be false (in
the if modifiers on the series of return statements), so that *is*
what was wrong (and the == implementation was different and didn't
encounter that problem).

Thanks again!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,208
Messages
2,571,079
Members
47,682
Latest member
TrudiConna

Latest Threads

Top