From: Trans <transfire@...>
Date: 2007-03-15T16:41:53+09:00
Subject: Re: Nil Comparable



On Mar 14, 9:59 am, ara.t.how...@noaa.gov wrote:
> On Wed, 14 Mar 2007, Trans wrote:
> > Does anyone see anything problematic about this?
>
> >  class NilClass
>
> >    include Comparable
>
> >    def <=>(x)
> >      x.nil? ? 0 : -1
> >    end
>
> >    def succ; nil; end
>
> >  end
>
> > It seems benign enough, and can be used to represent "always before".
> > For instance, in Rake there is a class called EarlyTime: "EarlyTime is
> > a fake timestamp that occurs before any other time value." And that's
> > all that it does. If NilClass were comparable per the above then
> > EarlyTime would not be needed.
>
> it could mask errors like
>
>    [42, nil].sort
>
> depending on the order of comparison it may or may not work since we might get
>
>    42.send '<=>', nil
>
> or
>
>    nil.send '<=>', 42
>
> so it's a bit different in that it's weakly typed where as the EarlyTime class
> is strongly typed - it'll only compare with other times
>
> still - it __is__ handy.  if you search the archives i've suggeted that
> -Infinity and Infinity have these kinds of properties wrst numerics a few
> times.

Infinity and _Infinity would be a better fit, I agree. But is it
possible for them to always be lesser or greater no matter if they are
the receiver or argument of a comparison? That's doesn't seem to fit
well with OOP design. And it's not very practical to add this
constraint to ever definition of <=> in every class. Although maybe
<=> could be defined in Kernel with the constraints and super could be
called to get that functionality. Eg.

  module Kernel
    def <=>(other)
      return  1 if -Infinity == other
      return -1 if  Infinity == other
      0
    end
  end

then

  class Integer
    def <=>(other)
      if (c = super) != 0 then return c
      ...

T.