From: Eero Saynatkari <ruby-ml@...>
Date: 2009-06-30T00:56:46+09:00
Subject: [ruby-core:24080] Re: [Feature #1697] Object#<=>

Excerpts from Marc-Andre's message of Mon Jun 29 15:35:52 +0300 2009:
> This really is a different and separate discussion though; one could
> also argue that  "nil =~ Date.new" should raise an error! Changing the
> semantics for <=> at this point would require a really compelling
> argument, since all existing Ruby code calling <=> or defining <=> has
> been written with the assumption that <=> should return nil when
> arguments can't be compared.

I disagree. Because there are currently no unified semantics
for #<=>, you are equally likely to find someone who relies
on a TypeError (or NoMethodError) being raised on an invalid
conversion. I think either change will require some people
to change their code, making the argument moot in terms of
which solution is "better."

(And indirectly, I think e.g. Array checks for a nil return
value and raises if it gets one.)

Is there a compelling case where not being able to compare
two objects is a valid expectation, and could not be better
addressed by actually implementing the comparison or some
other change in logic? On the flipside of that, there seems
to be potential for masking problems by evaluating to nil,
mostly in cases where #<=> is being used implicitly.

> My proposition doesn't change the semantics of <=>, rather it makes it
> is more respectful of it.

See above.


Eero
--
Magic is insufficiently advanced technology.