I just read a post advocating changing NilClass#method_missing to always return nil. Their argument is that you no longer have to check if you actually have something before calling methods on it like:
@sun && @sun.still_burning?
Instead, you could just call @sun.still_burning?, which is nice. I usually just check isthesunstillburning.com 20 times a day to make sure, but you get the point. *Edit:* it looks like this site is no longer up, and now I get worried at night, when I can’t tell
Now, it’s a very attractive, very short solution to an every day annoyance – that alone is enough to make me worry. Overriding #method_missing on NilClass just seems wrong. The better solution is to define Null Objects for all of your classes, and have those returned instead of nothing. Yeah, it’s more work than the method_missing solution, but it’s a lot safer and doesn’t leave such a bad taste in my mouth.
I do actually reopen NilClass though
Often, actually. Working with rspec and making typos can be very frustrating otherwise. If do @sum.should_recieve(:set) instead of @sun, then you’ll get
Mock 'some mock' received unexpected message :tyop? # or Mock 'NilClass' expected :list_pathways with ("hsa") once, but received it 0 times
The second one is easy to realize you have a typo, sure. But I know I’ve wasted time wondering why the expectation failed, and I’m sure you have too. By adding a few methods to NilClass, this is no longer an issue:
class NilClass def should_receive(*args) raise "WARNING: you tried to add expectations to nil!" end alias :stub! :should_receive end
Now we get:
WARNING: you tried to add expectations to nil! and even a line number to where the typo is.
When else have you found it okay to mess around with NilClass? I’m sure there are a few other occasions where it makes sense.
Sun picture from rodger smith, flickr