From: Robert Dober <robert.dober@...>
Date: 2007-03-15T18:16:10+09:00
Subject: Re: Nil Comparable

On 3/15/07, Trans <transfire@gmail.com> wrote:
>
>
> 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
Will that be good enough? People will often write their #<=> in classes.
Better than nothing of course.
>
> then
>
>   class Integer
>     def <=>(other)
>       if (c = super) != 0 then return c
>       ...
>
> T.
>
I really hate not having more time and/or knowledge.
I had talked about this twice on the list but the second time (the
peak of the iceberg) I never found the time to elaborate.

I am very unhappy with the <=> paradigm for Comparable I really prefer
the Less Pattern (no idea why it has that name, maybe I recall
incorrectly) should be LessEqual.
Tom I guess you are familiar with it - I have posted this before, sorry

module Comparable
# relies on #<= only
def < other; self <= other && ! other <= self end
def > other; other <= self && ! self   <= other end
def >= other; other <= self end
def == other; other <= self && self <= other end
def != other; ! self == other; end
end

At first sight there are two major advantages, we can use it for half
orders where neither x <= y nor y <= x hold !
And more important in your context the module Comparable enforces the
symmetry of the #<= method, it does not show up later when you are
sorting.

Performance of course is a catastrophe :(

Cheers
Robert
-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw