Hello,
I have written a class, which includes the Comparable Mixin. I implemented the <=> operator in a way, which maps it to the <=> operator in integer if applicable and returning nil otherwise. (This is how I observed it in the Integer class [irb line 006]). I now expected the == operator in my class to behave exactly like the == in Integer. This works fine, while it is applicable (if the Modnums have the same base). But if I return nil (just like Integer <=> String) <= is fine [line 009], but == behaves differently from what I expected. Why doesn't [line 11] return false like [line 10] does? I thought == is supposed to return true or false, nothing else?
Thanks for your help,
Manuel
···
----------------------
irb(main):001:0> require "modnum.rb"
=> true
irb(main):002:0> a = 5
=> 5
irb(main):003:0> b = "Hallo"
=> "Hallo"
irb(main):004:0> c = Modnum.new(3,7)
=> #<Modnum:0x101ae1c8 @base=7, @value=3>
irb(main):005:0> d = Modnum.new(3,9)
=> #<Modnum:0x101a6c20 @base=9, @value=3>
irb(main):006:0> a <=> b
=> nil
irb(main):007:0> c <=> d
=> nil
irb(main):008:0> a <= b
ArgumentError: comparison of Fixnum with String failed
from (irb):8:in `<='
from (irb):8
irb(main):009:0> c <= d
ArgumentError: comparison of Modnum with Modnum failed
from (irb):9:in `<='
from (irb):9
irb(main):010:0> a == b
=> false
irb(main):011:0> c == d
=> nil
Yukihiro Matsumoto said something:
"nil" denotes underlying assumption (<=> to return an integer value)
is not met.
Perhaps "mu" should be aliased to "nil"?
iain
···
--
"If sharing a thing in no way diminishes it, it is not
rightly owned if it is not shared." -- St. Augustine
#rm -rf /
http://www.geeksoc.org/
Yukihiro Matsumoto schrieb:
Hi,
>But if I return nil (just like Integer <=> String) <= is fine [line >009], but == behaves differently from what I expected. Why doesn't [line >11] return false like [line 10] does? I thought == is supposed to return >true or false, nothing else?
"nil" denotes underlying assumption (<=> to return an integer value)
is not met. Ruby sometimes use nil as a small error indicator.
matz.
Hi,
then why doesn't [line10] return nil? a <=> b is nil [6], so is c <=> d [7].
a == b returns false [10], while c == d returns nil [11]. I expected both to return nil or both to return false.
Thanks for your help,
Manuel Kasten
irb(main):002:0> a = 5
=> 5
irb(main):003:0> b = "Hallo"
=> "Hallo"
irb(main):004:0> c = Modnum.new(3,7)
=> #<Modnum:0x101ae1c8 @base=7, @value=3>
irb(main):005:0> d = Modnum.new(3,9)
=> #<Modnum:0x101a6c20 @base=9, @value=3>
irb(main):006:0> a <=> b
=> nil
irb(main):007:0> c <=> d
=> nil
irb(main):010:0> a == b
=> false
irb(main):011:0> c == d
=> nil
···
In message "Re: Question regarding <=> operator and Comparable Mixin" > on Thu, 10 Nov 2005 02:27:12 +0900, Manuel Kasten <kasten.m@gmx.de> writes:
>then why doesn't [line10] return nil? a <=> b is nil [6], so is c <=> d [7].
>a == b returns false [10], while c == d returns nil [11]. I expected >both to return nil or both to return false.
Right. Although it has its own good reason internally, it is
inconsistent. Those two lines should return same values. Let me
think about it. If you have any opinion, let me know.
I'd prefer returning false. I think it's odd if I test for equality and don't recieve a boolean in return.
But I'm new at Ruby so maybe nil makes sense, too (not for me, though).
Manuel