I need to define <=> in a class. What is the appropriate thing to do when
the “other” argument is not an object in the class? For example, comparing
myObject <=> nil, which actually happens in the debugger. Should I just
send it to the superclass?
Hi,
···
In message “Defining <=>” on 02/11/20, “Tim Hunter” cyclists@nc.rr.com writes:
I need to define <=> in a class. What is the appropriate thing to do when
the “other” argument is not an object in the class? For example, comparing
myObject <=> nil, which actually happens in the debugger. Should I just
send it to the superclass?
Return nil.
matz.
Tim Hunter wrote:
I need to define <=> in a class. What is the appropriate thing to do when
the “other” argument is not an object in the class? For example, comparing
myObject <=> nil, which actually happens in the debugger. Should I just
send it to the superclass?
If you can somehow coerce the other argument into the receiver’s class,
that would work. Otherwise, I think most or all of the built-in classes
just raise a TypeError exception.
Hi,
I need to define <=> in a class. What is the appropriate thing to do when
the “other” argument is not an object in the class? For example, comparing
myObject <=> nil, which actually happens in the debugger. Should I just
send it to the superclass?Return nil.
matz.
If you return nil, then future operations like < and sort will raise the
following error (1.6.5 Cygwin):
TypeError: no implicit conversion from nil
This is a bit cryptic. Is there any benefit to not just raising a TypeError
yourself (with a more relevant message) in the definition of <=> ?
Gavin
···
From: “Yukihiro Matsumoto” matz@ruby-lang.org
In message “Defining <=>” > on 02/11/20, “Tim Hunter” cyclists@nc.rr.com writes:
Thanks to everybody for their help! Actually, I had mistakenly asked two
questions in one. The first question should’ve been “what do I do in my
== method when the other argument isn’t an object in the same class?” The
answer is obviously “return false”.
The second question should’ve been “what about the <=> method?” and the
answer is “raise TypeError”.
Here’s more-or-less what I ended up with:
def ==(other)
return false unless other.kind_of? self.class
return (self <=> other) == 0 ? true : false
end
def <=>(other)
unless other.kind_of? MyClass
raise TypeError, "#{other.class} can't be coerced into MyClass"
end
# do the comparison & return the result
end
Any suggestions?
···
On Tue, 19 Nov 2002 21:13:11 +0000, Lyle Johnson wrote:
Tim Hunter wrote:
I need to define <=> in a class. What is the appropriate thing to do when
the “other” argument is not an object in the class? For example, comparing
myObject <=> nil, which actually happens in the debugger. Should I just
send it to the superclass?If you can somehow coerce the other argument into the receiver’s class,
that would work. Otherwise, I think most or all of the built-in classes
just raise a TypeError exception.
Hi,
···
In message “Re: Defining <=>” on 02/11/20, “Gavin Sinclair” gsinclair@soyabean.com.au writes:
Return nil.
If you return nil, then future operations like < and sort will raise the
following error (1.6.5 Cygwin):TypeError: no implicit conversion from nil
This is a bit cryptic. Is there any benefit to not just raising a TypeError
yourself (with a more relevant message) in the definition of <=> ?
This is a formal way in 1.7. I should modify 1.6.8 as well to handle
nil value.
matz.
Hi –
···
On Fri, 22 Nov 2002, Tim Hunter wrote:
Thanks to everybody for their help! Actually, I had mistakenly asked two
questions in one. The first question should’ve been “what do I do in my
== method when the other argument isn’t an object in the same class?” The
answer is obviously “return false”.The second question should’ve been “what about the <=> method?” and the
answer is “raise TypeError”.Here’s more-or-less what I ended up with:
def ==(other) return false unless other.kind_of? self.class return (self <=> other) == 0 ? true : false end def <=>(other) unless other.kind_of? MyClass raise TypeError, "#{other.class} can't be coerced into MyClass" end
do the comparison & return the result
end
Any suggestions?
Have you looked into using the Comparable module? I’m not sure
whether it’s a fit for what you’re doing, but if it is it might save
some manual method writing.
David
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
Hi,
Return nil.
If you return nil, then future operations like < and sort will raise the
following error (1.6.5 Cygwin):TypeError: no implicit conversion from nil
This is a bit cryptic. Is there any benefit to not just raising a
TypeError
yourself (with a more relevant message) in the definition of <=> ?This is a formal way in 1.7. I should modify 1.6.8 as well to handle
nil value.
matz.clone
dev.faster? # true
···
----- Original Message -----
From: “Yukihiro Matsumoto” matz@ruby-lang.org
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, November 19, 2002 10:34 PM
Subject: Re: Defining <=>
In message “Re: Defining <=>” > on 02/11/20, “Gavin Sinclair” gsinclair@soyabean.com.au writes: