Robert Dober
3/15/2007 9:16:00 AM
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