True, False And Nil Objects In Ruby

http://www.skorks.com/2009/09/true-false-and-nil-objects-in-ruby/

by askorkin • 17 years ago

18 20 17 years ago

ianbishop• 17 years ago

> Now if your code is playing with objects that quack like a duck and you end up with a nil instead of a DuckLike object, your nil object will be able to quack a sensible default value (or raise an error if you prefer).

I never knew this but it will definitely come in handy.

bhousel• 17 years ago

Because NilObject is actually an object, it is possible to add some methods that take some of the pain out of dealing with maybe-nil objects..

My favorite is the andand gem: http://github.com/raganwald/andand/tree/master

It lets you turn code like this..

   entry.at('description') && entry.at('description').inner_text

..into code like this..

   entry.at('description').andand.inner_text

masklinn5• 17 years ago

Why not stick to EAFP and go with something along the lines of:

    begin entry.at('description').index_text
    rescue NoMethodError; end

?

masklinn5• 17 years ago

> I never knew this but it will definitely come in handy.

It's also pretty dangerous if you don't have a very good test coverage (and good tests), because it hides potential bugs. And it can break code which relies on the default behavior of `nil` (or other built-in objects).

That's one of the biggest issues I have with monkey patching of builtin classes in Ruby or Smalltalk: it's not scoped/namespaced.

edit: by comparison, Haskell's operators redefinition is scoped, so though you can redefine `+` as `-`:

    Prelude> let (+) = (-) in print (3+5)
    -2

this redefinition will only span your module and won't affect third-party library (unless you export the change and they import it for course).

stcredzero4• 17 years ago

That's one of the biggest issues I have with monkey patching of builtin classes in Ruby or Smalltalk: it's not scoped/namespaced.

In Smalltalk, the right thing to do is use a subclass. Have that function return an instance of a subclass of UndefinedObject that's tailored to the context. Instead of returning nil, return a NotApplicable instance. Then you can have it print out a locale appropriate 'n/a' message when you need to display the value.

jerf4• 17 years ago

No, it's a terrible idea. You have no scoping and the nil object running around all parts of the system with you have no way of telling what's going to happen when you start redefining it for your sole and singular use.

The .andand hack is at least arguable, inasmuch as it adds behavior to nil itself that is at least applicable to nil, rather than "quacking" or anything else that has nothing to do with nil.

You are also begging to create a fragile, magical system that will randomly throw errors and die in strange places that seem to have nothing to do with the error itself or can't possibly happen. I speak from experience. Do not hide the fact you got a null when you didn't expect. Basically, your program is still going to crash, it's only a matter of when it goes and how much data it corrupts before it happens. You want it to die sooner, before it scrambles anything more. (Again, using "andand" is different as it shows that you were explicitly concerned about getting a null back and are doing what it takes to get the null out of the system; it's just refactored "if null then X else Y" which is fine.)

Suggesting that you rewrite nil for the purpose of hiding errors is an incredible immature thing to do; I'm sorry to have to call it out but given what it could do to people and how much of their lives could be wasted by following this suggestion it needs to be said strongly:

Do Not Do This.

(If Ruby could add scoped monkeypatching, the equation radically changes from "Do Not Do This" to "jerf is uncomfortable with this style but has no particular objections otherwise", which is a completely different thing; then I'd be expressing an opinion on style instead of warning you that you're going to create a nightmare system if you do that.)

(And yeah, I said null, not nil; that's because this applies to more than just Ruby and I wanted to keep it generic.)

KevinMS2• 17 years ago

Didn't read, too wide!

stcredzero4• 17 years ago

It's a bad idea to put methods on nil willy-nilly. I see stuff like this in Smalltalk projects all the time. People like to put < and > on nil and think they're clever because they fixed their little routine that does a sort. What they don't realize, is that they've possibly broken something else that depends on the Does Not Understand exception as part of its normal operation. (Yes, remember there's only one nil object, and you have no comprehensive list of what implicit contracts it has to fulfill in the rest of the code base. Certain proxy mechanisms can break. I know of another mechanism in one Smalltalk's streams that would break as well.)

The correct way to replace your nil checks with polymorphism is with the MissingObject pattern. Languages with explicit types should give you this for free. I think that even duck-typed languages should do this. (Every time you define a class Foo, you get MissingFoo automatically.) They can often be provided by libraries.

mrduncan• 17 years ago

This is a classic case of "just because you can, doesn't mean you should".

stcredzero4• 17 years ago

It's not just that. One should replace conditionals with polymorphism. It's just that, in this case, not enough thought is given to how. Namely -- how can I accomplish this without possibly breaking lots of other things?

jerf4• 17 years ago

Another option that I'm really warming to is to put it right in the type system whether or not you might have "Nulls". You can sort [Int] and you can sort [Maybe Int] if you provide the correct sort functions, but either way, there's no surprises. There simply will not be a "null" in an [Int].

While I'm using Haskell's notation, it seems likely that pretty much any strongly typed language could do something like this, at least ad hoc. (That is, Haskell hasn't actually written this into the typing system, it's just a direct use of the type system that it already had. But even a C++-like language could probably put this in there if it was written that way from day one; arguably, it's allowing the nulls to exist in the first place that is actually the hack.)

masklinn5• 17 years ago

> it seems likely that pretty much any strongly typed language could do something like this

No. Or more precisely, in a dynamically typed language (which may or may not be strongly typed) there's no point in doing so, it won't buy you anything expressivity or correctness over nullable references.

Pretty much any statically typed language would benefit from making names/references non-nullable by default and moving nullability into the type system yes.

> it's allowing the nulls to exist in the first place that is actually the hack

How is it a hack? It's trivial to implement, but there's nothing hacky about it.

raganwald2• 17 years ago

"The correct way to replace your nil checks with polymorphism is with the MissingObject pattern."

I strongly agree. Adding stuff to nil can have unintended consequences:

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

KevinMS2• 17 years ago

Rails does what he mentions ...

  [shell] ./script/console
  Loading development environment (Rails 2.3.3)
  >> nil.blank?
  => true
  >> "".blank?
  => true
  >> [].blank?
  => true
  >> {}.blank?
  => true

It lets you write cleaner code in situations when you don't care if an object is empty data or a nil. Avoiding the "whiney nils" ruby has a reputation for.

instead of

if myobj && myobj.size == 0 then :blah end

you can write

if myobj.blank? then :blah end

makes me miss perl though

True, False And Nil Objects In Ruby

Related Stories