@butter.expires.strftime ‘%m/%d/%Y’ rescue nil

Ummm… you know this does a LOT MORE than just handle the case where one of the object is nil, correct? This rescues any exception thrown for any reason and silently swallows it.

For example, what if other_object returns an object that is not null but does not have #attribute? NoMethodError, but it has nothing to do with nil. Or what if one of those methods actually performs a query, but your database is not available? Another exception, silently swallowed again.

There’s nothing wrong with writing that when you mean “I want to rescue any exception thrown for any reason and return nil without logging it or letting me know what the problem is, even if it’s my own programming error.”

But if what you mean is to handle cases where one of the receivers in the chain is nil, you might want to consider something a little more specific.

JM2C, I’m obviously biased :-)

object.child_object.other_object.attribute rescue nil

just returns nil if anything in the chain is nil.

Well, languages like Haskell enforce referential transparency, so 1. if you write Person.find(…) twice in the same expression without using Monads, they will always return the same thing, and 2. teh compiler knows this and will optimize things so that you don’t actually call the function twice.

That being said, it is not particularly DRY. In Scheme, I would use a let to introduce a variable limited in scope to the expression.

Personally I find using @var is more readable than the RAILSish solution to throw in Foobar.new(:blabla) all over the place.

The problem is, RoR is built with this from the ground up:
all_people = Person.find(:all)

This is almost native english language. The thing however you miss here is that in ESSENCE, it is still SHORT and TERSE, and this is GOOD.

The less code you write to achieve a goal, all the better.
It allows you to use any abstraction you want.

isn’t this so ugly? “@person ? @person.name : nil””

Absolutely nothing, provided you first write:

@person = …

If you don’t have an @person member variable (or person local), then you must choose between creating one just for this one use or finding another way:

Person.find(:first, … ) && Person.find(:first, … ).name

This cannot be right. After that, it’s a question of what you find readable. If I don’t need @person elsewhere, adding an extra assignment feels a little like the boilerplate “design patterns” I loathe in Java. But that’s just me :-)