Defining <=>

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: