Comments on: Object.too_clever_by_half? rescue nil

By: Reg Braithwaite

Reg Braithwaite — Mon, 07 Apr 2008 22:33:06 +0000

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.

By: robin

robin — Mon, 07 Apr 2008 08:52:17 +0000

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.

By: Eddie Welker

Eddie Welker — Sun, 06 Apr 2008 03:07:57 +0000

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.

By: Reg Braithwaite

Reg Braithwaite — Sun, 06 Apr 2008 00:06:35 +0000

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.