Hypsometry. Modal Synthesis.

Today I was working on a view helper that creates a link to show a list. Something like the following:

def list_control(options = {})
  options = do_stuff_with_the_parameters(options)
  render(:partial => "link/list_control", :locals => options)
end

One option you can pass in is new_count, which is the number of new items in the list. The new_count parameter, however, is optional, since only some lists care about the newness of their items. If there’s no new_count, then the list control doesn’t talk about it at all. And new_count can, of course, be 0, and when it’s 0 the list control notes that in the title attribute but nowhere else. (So that the information is still there, and you can access it if you care, but it’s invisible most of the time.) Only if new_count exists and is greater than 0 do we display it in the link’s name.

Since Ruby lets you check to see if an object is nil?, or if it’s zero?, or if it’s empty? (Array, Hash, and String, among many others), I figured there’d be some easy way of checking to see if new_count’s either nil or 0.

Well, to save you some Pickaxe thumbing and some googling, there ain’t.

Way back in 2005, why the lucky stiff suggested that Ruby be extended to include Object#blank?. (The actual Ruby change request has vanished from the RCarchive, so why’s write-up of it seems to be the only extant discussion.) He proposed the following:

class Object
  def blank?
    if respond_to? :empty?
      empty?
    elsif respond_to? :zero?
      zero?
    else
      !self
    end
  end
end

In other words, why’s Object#blank? looks to see if an object can be empty, and if so checks whether it is, in fact, empty. If the object can’t be empty but can be zero, then Object#blank? checks whether it is, in fact, zero. If the object can’t be empty or zero, then Object#blank? returns the negation of the object, which will be true if the object is nil or false, and false otherwise.

In other other words, why’s Object#blank? checks an object for all the ways in which it can be nothing, and returns true if any of them return true.

In other other other words, why’s Object#blank? is exactly what I wanted.

No wonder he said “I use this code in nearly all of my web application projects.”

So I went ahead and used count.blank?, then waited for the tests to start screaming at me. Strangely, they didn’t.

Back to Mister Google. Turns out that the clever buggers on Rails core had already added support for blank?. That’s nice, I thought; they’re a step ahead of me.

So I went ahead and wrote the code that does one thing if new_count doesn’t exist, another if it exists and is 0, and another if it exists and is not 0. And the code failed.

Back to the Rails Trac. Turns out that when the clever buggers on Rails core implemented why’s idea they left out the bit where 0 indicates blankness. empty? means blank, nil means blank, false means blank, but 0 means not blank.

Okay. That’s legitimate. Not what I need, but legitimate.

In the comments on why’s post, people thought of a lot of alternate names for blank?. I thought about it for a second, and realized that nihil? struck my fancy. Thus, Object#nihil?:

class Object
  def nihil?
    if respond_to?(:empty?)
      empty?
    elsif respond_to?(:zero?)
      zero?
    else
      not self
    end
  end
end

I threw it into /lib/nihil.rb and added require 'nihil' to the app’s initializer, and that was that. Onward.