From: Marc-Andre Lafortune <ruby-core-mailing-list@...>
Date: 2009-06-29T21:35:52+09:00
Subject: [ruby-core:24079] Re: [Feature #1697] Object#<=>

On Sun, Jun 28, 2009 at 2:12 PM, Eero Saynatkari<ruby-ml@kittensoft.org> wrote:
> For what it is worth, when Marc-Andre brought the topic up
> on #rubinius, I argued for it to always either return one
> of -1, 0, 1 or then raise an error; and to never return nil
> or any other value. The user may simply rescue (or not) and
> differentiate between errors as needed.

Arguments can be made as to what would be the best semantic for <=>.
Eero would prefer some kind of NotComparable exception raised. My
personal opinion is that <=> was created with the perfect semantic.

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.

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


Marc-Andr�