I like lazy instantiation: I define a variable and make it nil, and don't
assign it a non-nil value value (a Hash or Array, for example) until I have
something to put inside it.

I often find myself writing code like

    do_something unless hash.nil? || hash.empty?

Would it make sense to have nil (more properly NilClass) respond to more
messages like empty?, or would that break something? If nil responded to
methods like empty?, eql?, or zero?, we could write

    do_something unless hash.empty?

and not have to worry about whether hash is nil or not.

The only downside I can see to this is the possibly large number of methods
that nil would need to take on. Candidates might include all "?" methods
from Enumeration, Numeric, String, Array, and Hash. Perhaps NilClass could
define size() and length() to return zero.

Of course, I could always create a file containing

    class NilClass
	def empty?
	    return true
	end
	# ...
    end

but I don't want to require such a file in every script I write and I don't
want other coders to have to inherit scripts where I've noodled with nil.

Jim
-- 
Jim Menard   jimm / io.com   http://www.io.com/~jimm/   BeOS developer #1283
"Space Opera. It's not over until the fat lady explosively decompresses..."
    -- Matt Ruff / Lisa Gold, rec.arts.sf.written