More Prevention of NoMethodErrors on nil

Geplaatst door Michiel de Mare wo, 05 maa 2008 06:24:00 GMT

What a sudden interest in avoiding NoMethodErrors on nil lately! I’ve just thought of another method. (Remember, you can solve any problem by adding a layer of indirection.)

Say you have Remco’s canonical example:

Both person and may be nil. So we usually write: person && &&

Now for the level of indirection. Remember rrss? I’ve introduced it last month. It stands for “returns result, same self”. Its definition is beyond trivial:

class Object
  def rrss
    yield self
With rrss we can rewrite the original as: person.rrss {|p|}.rrss {|n| n.upcase} Or with to_proc notation: person.rrss(&:name).rrss(&:upcase). We still need to check for nil though:

person.rrss {|p| p &&}.
       rrss {|n| n && n.upcase}

Doesn’t this last bit look like it’s in need of a bit of refactoring? Its lack of DRY-ness jumps right out of the page.

First try:

x = lambda {|p| p &&}
y = lambda {|n| n && n.upcase}
Let’s use an array instead!

arr = [lambda {|p| p &&}, 
       lambda {|n| n && n.upcase}]
arr.inject(person) {|o,l| o.rrss(&l) }
We should use the nil test to within the inject block.

arr = [lambda {|p|}, 
       lambda {|n| n.upcase}]
arr.inject(person) {|o,l| o && o.rrss(&l) }
Hey, can’t we write those lambdas a lot nicer?

arr = [lambda(&:name), lambda(&:upcase)]
arr.inject(person) {|o,l| o && o.rrss(&l) }
Do we even need lambdas? We’re calling them with the ampersand(&), so to_proc will be called on them anyway.

arr = [:name,:upcase]
arr.inject(person) {|o,l| o && o.rrss(&l) }
Let’s turn this into a method!

class Object
  def chain(*a)
    a.inject(self) {|o,l| o && o.rrss(&l) }
We’ve made quite a journey. But look, we’ve come a long way!

# long ago
person && &&

# now

# with obedient nil
# (in alternate, bugless universe)

Why don’t we go a little further yet. What if we’re not worried about nil. What if the want to stop a calculation as soon as it’s zero?

result = if value == 0 then value else
  tmp = calc(value)
  if tmp == 0 then tmp else

We could write another method on object to handle just this. But let’s make it more generic. Let’s accept a block.

class Object
  def chain(*arr)
    arr.inject(self) do |o,lmb| 
      if block_given? 
        yield o,lmb
        o && o.rrss(&lmb)
How does this work in practice? First, we need to define the chain, and Symbol#to_proc won’t cut it anymore. We’ll need lambdas.

chain = [lambda {|v| calc(v) }, 
         lambda {|v| more_calc(v)}]
Lambdas are ugly, but even so, that wasn’t so bad. Now, let’s use it!

value.chain(*chain) do |v,lmb| 
  v == 0 ? v : lmb[v]

Of course, the more steps you have, the bigger the gains of this method. With two steps, it’s a toss up. With three of more steps, you can go a long way in cleaning up your code.

Geplaatst in ,  | 7 reacties


  1. Reg Braithwaite zei ongeveer 8 uur later:

    Chain is DEFINITELY a monad. It seems we Rubyists are doomed to reinvent Haskell as well as Smalltalk and Lisp.

    But it is interesting to evolve our understanding through use and to discover why certain features exist in languages like Lisp and Haskell.

  2. Michiel zei ongeveer 8 uur later:

    Sure it’s a monad. But “monad” sounds scary! They need better marketing, and dropping the name seems a useful first step.

    Also, I think that Haskell’s static types distract from the essence from monads, which is in my view adding a layer of indirection between chained method invocations.

  3. Ivan Vega zei ongeveer 11 uur later:


    I don’t understand, what’s wrong with just redefining method_missing on NilClass?

  4. Michiel zei ongeveer 12 uur later:

    People often call a method on what they thought was an object but what turned out to be nil. This is the single most common source of bugs.

    This kind of bug can be caught because the method call is intercepted by NilClass#method_missing. This method raises an exception with a useful message.

    By redefining method_missing you give up this extremely useful diagnostic message.

  5. Ivan Vega zei ongeveer 14 uur later:

    Ah, I see.

    Isn’t it possible (this may sound ridiculous, but I’m no expert) to use something like by making the chain method return a subclass of NilClass which isn’t “whiny”?

  6. Jacob Maine zei ongeveer 15 uur later:

    You can get rid of the lambdas with this:

    class Object
      def chain(*arr)
        arr.inject(self) do |o,lmb| 
          if block_given? 
            yield o, method(lmb).to_proc
            o && o.rrss(&lmb)

    Which lets you write:

    value.chain(:calc, :more_calc) do |v,lmb| 
      v == 0 ? v : lmb[v]

    Probably crazy block scope bugs, but interesting anyway.

  7. Tom Moertel zei 1 dag later:

    Reg is right: the block

    {|o,l| o && o.rrss(&l) }

    is similar the bind rule for the Maybe monad. (I say “similar” because if you want to more fully adhere to Maybe-monad semantics, you’ll need to make sure that false is not mistaken for a “nothing” value:

    {|o,l| o.nil? ? nil : o.rrss(&l) }

    You’ll also need to bar side effects to be able to satisfy the monad laws.)

    In effect, we are defining nil to represent the result of a computation that returns nothing (fails), and we’re defining any non-nil value to represent the result of a computation that succeeds in producing a value. Then our bind rule takes the result o of a previous computation (successful or failed) and a method l that, given a successfully produced value, computes a new value (or itself fails). From this, bind generates a new computation that:

    • fails immediately if o represents a failure;
    • fails after evaluating o.l if the evaluation results in failure; or
    • returns the successfully computed result of o.l.

    A chain of such computations has the nice property that the chain will stop evaluating subsequent l methods after the first failure. (In a non-strict language, it’s easy to make the entire computation halt after the first failure.)


(Laat url/e-mail achter »)