It also helps make it clear what the methods actually do. I know of a bunch of methods in a certain code base ;) that … well it’s taking me a long time to figure exactly what they do and what tests to write for them.

Very useful methods anyway… I’d hacked some really quite unpleasant solutions to that little problem before I discovered them.

I ran into the exact same issue today, and after following the link from your post above, I found the solution in the form of the “keep” method.

In my case, I have three actions; a, b & c, where a redirects to b with a flash message, and b redirects to c. By default, the flash message is lost by the time c is rendered.

To get around the problem, I changed action ‘b’ as follows:

def b
…
flash.keep
redirect_to :action => :b
end

Now when c is rendered, the message set in a is present.

Thanks anyway for the link!

I hear only good things about NetBeans. I really should give it a try. Watch this space.

BTW, as I have said before, Netbeans is very impressive with full RoR and SVN support. It’s at 6.1RCx now and it has great ‘intellisense’ behaviour for API lookup. It’s really fast too. Don’t forget to hold down the ctrl key and move the mouse over your code. Blue highlights appear on definitions it recognises. It has refactoring and everything. Just like java even… !

$` and $’ are the text before regexp match and text after regexp match, respectively.

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.

#andand isn’t a good example to have there.

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.

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.