From: Austin Ziegler <austin@...>
Date: 2002-06-14T03:35:00+09:00
Subject: Re: Relational operators redux (returning RHS)

On Fri, 14 Jun 2002 02:05:07 +0900, Christoph wrote:
> "Austin Ziegler" <austin@halostatue.ca> wrote in
>> is fundamentally sound (warning; the following is untested
>> air-code).
> Still way above my standard;-)

Heh. Actually, it was tested, and I just forgot to remove that out.

>> alias :oeq, :==
>> 
>> def == (other)
>>     if other.nil?
>>         false
>>     elsif oeq(other)
>>         other
>>     else
>>         false
>>     end
>> end
> This would also imply false == false # => false

Just as we'd have to do with NilClass#==, FalseClass#== would be
necessary:

class FalseClass
    def ==(other)
        if other.kind_of?(FalseClass)
            true
        else
            false
        end
    end
end

Or something like that. It's not pretty, but I think that there's
few edge cases around this particular concept which would have to be
dealt with, and NilClass#== and FalseClass#== should take care of
most of them. I think. (The fact that most classes seem to get their
#== from Comparable helps.)

>> As I said, I *like* the idea that nil isn't equal to anything,
>> including nil.

> I don't like this idea, and I am not so sure if the C-heritage of
> 
> nan = 0.0 / 0.0
> nan.equal? nan # => true but
> nan == nan # => false
> 
> is really such a good idea.

I don't see why it's a bad idea. It does present a few surprises to
people who aren't used to a language distinguishing between 0 and
NULL, but it's intimately familiar to people who do anything with
SQL databases. Literally, when I set colval = NULL in a database, I
am setting it to an 'unset' value, which means that I can't possibly
trust anything about that value except the fact that it's unset.

It's rather like doing the following in C (dangerous and stupid):

    int *p, *c;

    if (*p == *c)
        puts("Miracle!");

We haven't initialised the pointers p & c, so we're picking up
whatever values are there. The likelihood of these values actually
matching is minimal. In C, NULL is simply 0, which represents its
*own* danger. I think that Ruby has a great step toward what I
consider Very Good NULL value handling (the more explicitly you
handle unset values, the better, as far as I'm concerned), but I
think that this would actually make it even better (that is, more
explicit).

If something isn't a "real" value -- much like NaN isn't a real
value but a concept, the same with nil, why should testing that
imaginary value against itself result in equality? By definition,
these 'values' aren't actually values, but concepts.

Just my .02 Canadian,
-a
-- Austin Ziegler, austin@halostatue.ca on 2002.06.13 at 14.22.12