Forum: Ruby Nil Comparable

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-03-14 14:48
(Received via mailing list)
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.

T.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2007-03-14 15:00
(Received via mailing list)
On Wed, 14 Mar 2007, Trans wrote:

>    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.

cheers.

-a
3f6fd7601005ebd3099d28abd30ab294?d=identicon&s=25 Ronnie (Guest)
on 2007-03-14 16:13
(Received via mailing list)
ara.t.howard@noaa.gov wrote:
>>    end
>
>
> cheers.
>
> -a
The Facets library includes all of the above-mentioned features of
usefulness.
http://facets.rubyforge.org/
There are a lot of other extensions to the Ruby core in it, and they can
mostly be included in small chunks, so they are easy to use.
I hope this helps!

Thus spake the monkey
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-03-14 21:58
(Received via mailing list)
On Mar 14, 11:12 am, Ronnie <k...@rpg-free.com> wrote:
> >>      x.nil? ? 0 : -1
> >> EarlyTime would not be needed.
> > or
>
> > cheers.
>
> > -a
>
> The Facets library includes all of the above-mentioned features of
> usefulness.http://facets.rubyforge.org/
> There are a lot of other extensions to the Ruby core in it, and they can
> mostly be included in small chunks, so they are easy to use.
> I hope this helps!


He he... The code I listed actually came right from Facets :)

Much thanks though!

T.
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-03-14 23:27
(Received via mailing list)
On 3/14/07, Ronnie <koko@rpg-free.com> wrote:
> >>      x.nil? ? 0 : -1
> >> EarlyTime would not be needed.
> > or
> >
> > cheers.
> >
> > -a
> The Facets library includes all of the above-mentioned features of
> usefulness.
> http://facets.rubyforge.org/
> There are a lot of other extensions to the Ruby core in it, and they can
> mostly be included in small chunks, so they are easy to use.
> I hope this helps!
Well I guess Tom knows about Facets Ronnie :)
http://rubyforge.org/projects/facets/
as you might know this link :).
>
> Thus spake the monkey
>
>
It must be quite rewarding though to get pointed to your own project I
would love that ;)

Cheers
Robert
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-03-15 01:41
(Received via mailing list)
On Mar 14, 6:26 pm, "Robert Dober" <robert.do...@gmail.com> wrote:

> It must be quite rewarding though to get pointed to your own project I
> would love that ;)

Yes, and rather surprising at the same time. I'm not sure what to make
of it actually.

T.
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-03-15 07:04
(Received via mailing list)
On 3/15/07, Trans <transfire@gmail.com> wrote:
> T.
>
As a matter of fact it is remarkable how you use the list as a tool to
improve the code and ideas of facets ...
Poor Ronnie got caught by your humble attitude, but it was funny - in
a nice way.

Personally for what it is worth:
I avoid his kind of trickery with core classes when I think my code
might become an API and I use it freely in applications (e.g. DSLs).
Now I am really not studied enough to tell you: DONT, but that would
be my advice if I were forced to give one.
This aligns pretty well with recent posts and the point of view from
learned gurus like David or Ara, I still might fail to see the whole
picture of course.

Cheers
Robert
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-03-15 08:42
(Received via mailing list)
On Mar 14, 9:59 am, ara.t.how...@noaa.gov wrote:
>
> it could mask errors like
>
> 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.
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-03-15 10:16
(Received via mailing list)
On 3/15/07, Trans <transfire@gmail.com> wrote:
> > >    def <=>(x)
> > > all that it does. If NilClass were comparable per the above then
> > or
> Infinity and _Infinity would be a better fit, I agree. But is it
>       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
This topic is locked and can not be replied to.