Don't overload #nil? in Ruby (opens in new tab)

(paul.rosania.org)

90 pointstessro14y ago38 comments

38 comments

Having recently worked with a Ruby codebase where anything could be nil at anytime, I consider even references to nil to be a code smell. Developers are inherently prone to ignoring error handling, so they'll happily ignore the fact that Order#customer really means Order#customer_or_nil. And when they see errors in production, they'll slap an andand on it and call it fixed. The code becomes extremely difficult to reason about.

I prefer that functions throw an exception when unable to do what they promised, rather than return nil or a null object. The try-catch block serves as documentation that the function might fail. If someone forgets to catch the exception, it will shut everything down rather than leave the program in an unanticipated state that could lead to an error elsewhere.

DanielRibeiro14y ago

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3].

Scala's standard library provides very helpful information on how to replace null with its Maybe class (called Option in Scala). Just take a peek into their collections library[4], and search for Option.

[1] http://www.infoq.com/presentations/Null-References-The-Billi...

[2] http://moonbase.rydia.net/mental/writings/programming/monads...

[3] http://andand.rubyforge.org/

[4] http://www.scala-lang.org/api/current/scala/collection/immut...

aphyr14y ago

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3].

Do you have a source for this? I was under the impression nil was directly taken from Smalltalk, which derived it from Lisp.

1 more reply

sdevlin14y ago

This is something that's nice about ML-family languages. Data is not "nullable" by default. If you want to introduce that possibility, you need to wrap it in some form of "option" type - and you're forced to deal with the consequences of that explicitly.

mcobrien14y ago

I'm not sure I like it, but this works

    def nil.method_missing(*args, &block); end

So now you can call nil.whatever.you.like and get nil. It's also still falsy, but now every nil value in your app silently works and doesn't throw an error.

It's both impressive and scary that Ruby lets you (or that new contractor you're not sure about) change the fundamentals of the language in one line of code.

raganwald14y ago

Some consequences:

https://github.com/raganwald/homoiconic/blob/master/2009-02-...

bodhi14y ago

I recall that this was the default action of Smalltalk? I can't find a reference though, so I am very likely incorrect.

In Objective-C nil will absorb any messages too, see the section "Sending Messages to nil" in http://developer.apple.com/library/ios/#DOCUMENTATION/Cocoa/...

spooneybarger14y ago

It isn't the default action in smalltalk. nil does not silently absorb messages in smalltalk.

regularfry14y ago

I've said this in a comment at rosania.org, but I think it bears repeating here: this is why we need a #blank? or #null? protocol that user classes can participate in as part of core. #nil? and an inextensible FalseClass just aren't enough to do the sorts of thing that Avdi was trying to do in his original post. My tentative proposal is languishing here: http://redmine.ruby-lang.org/issues/5372

jasiek14y ago

I guess that overriding the behavior of any built-in classes in Ruby is not a great idea, as most gems rely on that unmodified behavior.

DanielRibeiro14y ago

As a gem creator, is is terrible.

As a application creator, is is only bad when/if you open source part of it. Otherwise, you can always run the gems' tests against the compillation of your env.

jaylevitt14y ago

There's talk of "traits" for Ruby 2.0 that will let you scope your monkeypatching.

Confusion14y ago

Conceptually, nil != false. You shouldn't use 'nil' to mean 'false'. You should always test explicitly for nil-ness using #nil?. If you write

  if finished?
    do_something
  end

then finished? is not expected, and may not, return nil.

If you expect some_value to be able to be nil (which, for boolean values, is hardly ever), you should write

  if !some_value.nil? && some_value
    do_something
  end

In the end, these 'convenient' coercions that allow you to use any value as a boolean only come back to bite you, because unexpected stuff happens when stuff is unexpectedly nil. If it makes my coworkers cry that an object is nil and true at the same time, then they are at fault, not me.

Edit: and more importantly (I forgot to point this out explicitly) a non-nil value != true. That any string or integer is 'true' can lead to very hard-to-find bugs.

necubi14y ago

Such code is everywhere in the Ruby community and explicitly endorsed by many. I have never seen code like your second example in the wild, and it's far more complicated than the idiomatic way of writing it:

   if some_value
     do_something
   end

It's a core expectation of the language that !!nil_thing == false, so why violate it?

Confusion14y ago

Because when you write

  if !some_value
     do_something
  end

you often don't actually want it to be executed when some_value is nil instead of false. And when it is, you go scratching your head and searching where some_value came from, to discover some silly typo.

In some ways, the reverse is even worse: when you write

  if some_value
    do_something
  end

and you change some_value from nil to some sensible default like '', you will forget to update this clause and you will not understand why the code is being executed. If you use

  if !some_value.nil?
    do_something
  end

you don't have that problem, because the nil-test sticks out like a sore thumb.

2 more replies

perfunctory14y ago

I actually agree with Confusion. All these implicit coercions _will_ bite you. Don't understand why his post is downvoted.

anonymoushn14y ago

If the language ships with falsy nils, I don't think it's unreasonable to assume that nil values are also falsy.

jbert14y ago

By the same argument, nil != true.

This could lead to a tri-state ifs (with true/false/nil branches).

Or you can just consider that 2-branch 'if' runs the first branch if the test expr is true and the second 'otherwise'. (So that doesn't make nil false, it just makes it non-true).

And then your interpretation and everyone else co-exists and we can all code together.

schukin14y ago

You probably shouldn't use 'nil' to mean 'false', but since pretty much every compiler / interpreter out there will take the same branch when given a condition that's either nil or false, I'd say it's much safer to stick w/ what's existed for decades rather than accommodate some sort of tri-state boolean.

Confusion14y ago

Well, the tri-state boolean was a worst-case, but consistent, example. I did mention you should hardly ever need that ;)

riffraff14y ago

IME using any value as boolean never caused me any problem, neither in ruby nor in other languages where the same is possible.

What stuff should happen when something is unexpectedly nil if you tested it for truth-ishnes? Once you have written

    if not some_value
      something with some_value
    end

the only things you can do with `x` are things you can do with `false`, which are not many.

Confusion14y ago

See my response to necubi. The main problem is the reverse:

  if some_value
    something with some_value
  end

where you first use nil to signal false, but later change the base case of some_value from nil to 0, nil to NullObject or nil to some other base value. Since you think of these base cases as 'nothing', you will forget to change this related conditional the first time around, because it seems it would still do the right thing.

derefr14y ago

Isn't this a flaw in Ruby, though? It also means that you can't create a delegate/decorator/proxy object for a false object and have it be false as well, which goes against the general "everything is determined by sending messages" vibe Ruby has going on.

I know the reasoning (it's much faster to do math on object IDs than it is to call a method), but there are workarounds for this (e.g. only allowing frozen objects to be boolean-false, and having the object's truth-ness/false-ness represented by the return value of its #false? method at the time of freezing—thus allowing the interpreter to locate it in a semantically-meaningful part of object-ID space that can later be masked for in a TEST instruction.)

regularfry14y ago

With infinite spare time, what I'd try would be to make NilClass usable as a base class. The way that would work would be to have all instances of classes inheriting from NilClass live in the 0bXXX...XXX100 object ID space. Nil is currently 0b100, which is consistent, and this doesn't clash with any of the other immediates - it just translates to a different memory alignment rule in MRI.

adestefan14y ago

The ruby people will tell you that ruby's x, where x is power, flexibility, etc., comes from the ability to shoot yourself in the foot so just don't shoot yourself in the foot.

raganwald14y ago

Speaking as a Ruby user, I think nil and the entire behaviour around truthyness and falseness are wrong. I should be able to create my own nil objects, and I especially would love to be able to create false objects that carry more information.

For example (and there are code smells in this, but it gets the idea across):

    if account = Account.create(params[:account])
      ...
    else
      complainAbout account.errors
    end

Truthiness should not be reserved for whether an object exists, it could also be used for whether it is valid, complete, or anything else.

My particular example might not be a great one, but I think framework and library developers ought to be able to work a consistent use for truthiness and falseness into their creations, e.g. a true object has been saved, a true object is valid, a true object is complete, a true object represents the current state of the world instead of the past or future or a wrong state, and so forth.

3 more replies

j / k navigate · click thread line to collapse

38 comments

bluesnowmonkey14y ago

DanielRibeiro14y ago

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3].

[1] http://www.infoq.com/presentations/Null-References-The-Billi...

[2] http://moonbase.rydia.net/mental/writings/programming/monads...

[3] http://andand.rubyforge.org/

[4] http://www.scala-lang.org/api/current/scala/collection/immut...

aphyr14y ago

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3].

Do you have a source for this? I was under the impression nil was directly taken from Smalltalk, which derived it from Lisp.

1 more reply

sdevlin14y ago

mcobrien14y ago

I'm not sure I like it, but this works

    def nil.method_missing(*args, &block); end

So now you can call nil.whatever.you.like and get nil. It's also still falsy, but now every nil value in your app silently works and doesn't throw an error.

It's both impressive and scary that Ruby lets you (or that new contractor you're not sure about) change the fundamentals of the language in one line of code.

raganwald14y ago

Some consequences:

https://github.com/raganwald/homoiconic/blob/master/2009-02-...

bodhi14y ago

I recall that this was the default action of Smalltalk? I can't find a reference though, so I am very likely incorrect.

In Objective-C nil will absorb any messages too, see the section "Sending Messages to nil" in http://developer.apple.com/library/ios/#DOCUMENTATION/Cocoa/...

spooneybarger14y ago

It isn't the default action in smalltalk. nil does not silently absorb messages in smalltalk.

regularfry14y ago

jasiek14y ago

I guess that overriding the behavior of any built-in classes in Ruby is not a great idea, as most gems rely on that unmodified behavior.

DanielRibeiro14y ago

As a gem creator, is is terrible.

As a application creator, is is only bad when/if you open source part of it. Otherwise, you can always run the gems' tests against the compillation of your env.

jaylevitt14y ago

There's talk of "traits" for Ruby 2.0 that will let you scope your monkeypatching.

Confusion14y ago

Conceptually, nil != false. You shouldn't use 'nil' to mean 'false'. You should always test explicitly for nil-ness using #nil?. If you write

  if finished?
    do_something
  end

then finished? is not expected, and may not, return nil.

If you expect some_value to be able to be nil (which, for boolean values, is hardly ever), you should write

  if !some_value.nil? && some_value
    do_something
  end

Edit: and more importantly (I forgot to point this out explicitly) a non-nil value != true. That any string or integer is 'true' can lead to very hard-to-find bugs.

necubi14y ago

   if some_value
     do_something
   end

It's a core expectation of the language that !!nil_thing == false, so why violate it?

Confusion14y ago

Because when you write

  if !some_value
     do_something
  end

In some ways, the reverse is even worse: when you write

  if some_value
    do_something
  end

and you change some_value from nil to some sensible default like '', you will forget to update this clause and you will not understand why the code is being executed. If you use

  if !some_value.nil?
    do_something
  end

you don't have that problem, because the nil-test sticks out like a sore thumb.

2 more replies

perfunctory14y ago

I actually agree with Confusion. All these implicit coercions _will_ bite you. Don't understand why his post is downvoted.

anonymoushn14y ago

If the language ships with falsy nils, I don't think it's unreasonable to assume that nil values are also falsy.

jbert14y ago

By the same argument, nil != true.

This could lead to a tri-state ifs (with true/false/nil branches).

Or you can just consider that 2-branch 'if' runs the first branch if the test expr is true and the second 'otherwise'. (So that doesn't make nil false, it just makes it non-true).

And then your interpretation and everyone else co-exists and we can all code together.

schukin14y ago

Confusion14y ago

Well, the tri-state boolean was a worst-case, but consistent, example. I did mention you should hardly ever need that ;)

riffraff14y ago

IME using any value as boolean never caused me any problem, neither in ruby nor in other languages where the same is possible.

What stuff should happen when something is unexpectedly nil if you tested it for truth-ishnes? Once you have written

    if not some_value
      something with some_value
    end

the only things you can do with `x` are things you can do with `false`, which are not many.

Confusion14y ago

See my response to necubi. The main problem is the reverse:

  if some_value
    something with some_value
  end

derefr14y ago

regularfry14y ago

adestefan14y ago

The ruby people will tell you that ruby's x, where x is power, flexibility, etc., comes from the ability to shoot yourself in the foot so just don't shoot yourself in the foot.

raganwald14y ago

For example (and there are code smells in this, but it gets the idea across):

    if account = Account.create(params[:account])
      ...
    else
      complainAbout account.errors
    end

Truthiness should not be reserved for whether an object exists, it could also be used for whether it is valid, complete, or anything else.

3 more replies

j / k navigate · click thread line to collapse