Monkey-patching proposals have abounded in the Ruby community recently - including, but not limited to Object#andand, Object#_? and SafeNil and Object#method_.
The underlying aim of all seems to be to keep code as DRY as possible. Inline validity checking is considered too ugly and verbose, as in the following snippet:
@person.name unless @person.nil?
Most of the proposals, however, make no mention of Ruby’s exception handling routines. These routines are designed for the very purpose of removing unpleasant and repetitive error-handling procedures from code, and could be readily utilized in most or all the examples I have seen.
Ruby’s dynamic language features are powerful and alluring: but I believe that altering the fundamental behaviour of NilClass, as some have suggested, should be avoided wherever possible - and that probably means always.
Or to put it another way: When does DRY become more important than KISS?
4 Comments
First, I’m not sure why you mention Object#andand in the same breath as SafeNil. The former does not modify any exiting methods in either Object or in NilClass.
Second, I am confused by the example you give. There is NOTHING wrong with writing @person.name unless @person.nil?. The documentation for #andand specifically agrees with you. This is because looking up @person is cheap and free of side effects.
Whereas, if you needed to do something expensive and/or something with side effects, you would have to manufacture an instance variable to memoize your operation.
The choice I face is when to write:
begin
temp_person = Person.find(…)
temp_person.name if temp_person
end
And when to write:
Person.find(…).andand.name
I am all for the former if you prefer it, if you find it easier to read or aunderstand, and if the idea of adding the method #andand to the Object class keeps you up late at night. It is much less invasive than changing the behaviour of NilClass, but if it’s too much for you on principle, I have no problem with that.
But let’s be clear on the use case. @person.name unless @person.nil is NOT the use case.
Finally, I cannot answer for anyone else. But I do think that for me, DRY is KISS. If you think Object#andand makes the code less simple, than I agree you should eschew it. But it is not intended to be a tool for making things DRY at the expense of KISS, it is inteded to make things DRY and simpler.
I agree with Reg, it does seem to me that #andand is trying to be both DRY and KISS. To use it or not… it simply depends on the audience. If you’re at a ruby-familiar place, and understand what modifying Object means, that’s fine.
I work with a ton of bright people but I’d feel guilty using it (despite liking it), because I would know I’d slow down the next guy when he read it.
It’s all just a case of various levels of compromise, and over an idiom at that.
Reg, point taken - I wrote the list of links giving a broad overview. And then wrote the rest of the post, which went in a slightly different direction.
#andand isn’t a good example to have there.
Robin:
Well, in all fairness to KISS, what if a project suffers “The death of a thousand hacks”? IOW, Maybe #andand looks like a good idea. And so does #let (http://ick.rubyforge.org). And so does Symbol#to_proc. And so does X and Y and Z.
On a case-by-case basis, each may seem like a very good idea that has a positive ROI, is worth the time to learn.
But taken in aggregate, the code may be incomprehensible without serious study to learn each “idiom.”
I don’t know the answer to that one, it’s a legitimate problem.