The Ternary/AndAnd Destroyer

I just ran across this Hobo blog post which describes an awesome way to get rid of a lot of use cases for the ternary or && operator.

A lot of the time I end up doing stuff like Something.something_else[:huh] ? Something.something_else[:huh].do_stuff : nil or Something.something_else[:huh] && Something.something_else[:huh].do_stuff and if I’m worried about how long it takes to evaluate Something.something_else[:huh] I’ll even go so far to make it (s = Something.something_else[:huh]) && s.do_stuff. Very ugly indeed. Now with this new operator we can just do: Something.something_else[:huh]._?.do_stuff. It’s so cool!

What it does is define the method _? on Object which just returns self and define _? on nil which returns a proxy object that returns nil if you try to call any method on it which doesn’t exist on nil (instead of raising an exception). And if the method does exist on nil it will pass the method call through to it.

The way Hobo wrote the proxy object was like this:

class SafeNil
  def method_missing(*args, &b)
    nil.send(*args, &b) rescue nil
  end
end

I knew that rescue blocks are slow in general. So I made this optimization and saw a 2000% increase in speed:

class SafeNil
  def method_missing(method, *args, &b)
    return nil  unless nil.respond_to? method
    nil.send(method, *args, &b) rescue nil
  end
end

We can also optimize a little more and get another 2x speed increase. Instead of instantiating a new SafeNil object every time we you call ._? on nil we can always return the same object. There’s a lot of different ways to do this, I just used the singleton pattern:

class NilClass
  def _?
    SafeNil.instance
  end
end

class SafeNil < BasicObject
  include Singleton

  undef inspect

  def method_missing(method, *args, &b)
    return nil  unless nil.respond_to? method
    nil.send(method, *args, &b)  rescue nil
  end
end

The only time when you won’t want to use my version is if you indulge in metahaxxing the nil object with method_missing because respond_to? will not be accurate if you use method_missing to route method calls.

I used the ‘facets’ library’s BasicObject because it provides us with a clean slate. It is similar to Object except it has almost all the standard methods stripped away so that we will hit method_missing for almost all method routing.