Nil Comparable

Discussion in 'Ruby' started by Trans, Mar 14, 2007.

  1. Trans

    Trans Guest

    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.
    Trans, Mar 14, 2007
    #1
    1. Advertising

  2. Trans

    Guest

    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.

    cheers.

    -a
    --
    be kind whenever possible... it is always possible.
    - the dalai lama
    , Mar 14, 2007
    #2
    1. Advertising

  3. Trans

    Ronnie Guest

    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.
    >
    > 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
    Ronnie, Mar 14, 2007
    #3
  4. Trans

    Trans Guest

    On Mar 14, 11:12 am, Ronnie <> wrote:
    > 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.

    >
    > > 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.
    Trans, Mar 14, 2007
    #4
  5. Trans

    Robert Dober Guest

    On 3/14/07, Ronnie <> wrote:
    > 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.
    > >
    > > 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
    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
    Robert Dober, Mar 14, 2007
    #5
  6. Trans

    Trans Guest

    On Mar 14, 6:26 pm, "Robert Dober" <> 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.
    Trans, Mar 15, 2007
    #6
  7. Trans

    Robert Dober Guest

    On 3/15/07, Trans <> wrote:
    >
    >
    > On Mar 14, 6:26 pm, "Robert Dober" <> 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.
    >

    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


    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
    Robert Dober, Mar 15, 2007
    #7
  8. Trans

    Trans Guest

    On Mar 14, 9:59 am, 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.
    Trans, Mar 15, 2007
    #8
  9. Trans

    Robert Dober Guest

    On 3/15/07, Trans <> wrote:
    >
    >
    > On Mar 14, 9:59 am, 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
    Robert Dober, Mar 15, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brian Candler

    puts nil generates "nil\n"

    Brian Candler, Nov 6, 2004, in forum: Ruby
    Replies:
    1
    Views:
    111
  2. John Carter
    Replies:
    64
    Views:
    640
    Klaus Stein
    May 19, 2005
  3. ako...

    a == nil or a.nil?

    ako..., Nov 22, 2005, in forum: Ruby
    Replies:
    6
    Views:
    143
    Douglas Livingstone
    Nov 23, 2005
  4. Christoffer Sawicki
    Replies:
    5
    Views:
    254
    Christoffer Sawicki
    Sep 2, 2006
  5. Robert Schaaf

    Making nil comparable.

    Robert Schaaf, Jun 5, 2009, in forum: Ruby
    Replies:
    5
    Views:
    97
    Joel VanderWerf
    Jun 5, 2009
Loading...

Share This Page