From: Austin Ziegler <austin@...>
Date: 2002-10-26T03:43:21+09:00
Subject: Re: How come true, false don't support <=> (comparison) operator?

On Sat, 26 Oct 2002 03:18:12 +0900, Marcin 'Qrczak' Kowalczyk wrote:
> Fri, 25 Oct 2002 20:59:36 +0900, dblack@candle.superlink.net
> <dblack@candle.superlink.net> pisze:
>> I guess one reason is that it's not clear (to me, anyway) why
>> true would be > false, or false > true. Is there ordinality to
>> Boolean values?
> I find 'false <true' in all languages I know. Do you know any
> where it's otherwise?

Actually, in C, that's not necessarily the case. 'false' is integer
0, whereas true is *properly* defined as !0 -- which may be either
one (0x00000001) or -1 (0xFFFFFFFF). Now, if truth is measured
exclusively with unsigned values, then false < true is always true
-- but with signed values, that's not necessarily the case.

(:

When I was doing something recently that required boolean <=>
comparison, I did:

    if a != b
        a ? -1 : 1
    end

This somewhat assumes that false < true, but really in this case it
says which side of the comparison is "more different" different than
the other side. (I actually did it backwards in the code for
Text::Format, where true < false.) It's a useful comparison at
times, and a nice solution without resorting to #to_i.

Similarly, for arrays (which don't recognise <=> either if either is
empty -- they should, though), I do:

    if a.empty? || b.empty?
        if a.empty? && !b.empty?
            -1
        elsif !a.empty? && b.empty?
            1
        else
            0
        end
    end

This one is easier to deal with, because there is an absolute size
comparison *first*.

-austin
-- Austin Ziegler, austin@halostatue.ca on 2002.10.25 at 14.24.11