I like the functionality, but the name doesn’t quite “click” to me either.

Bang methods have different semantics… what about “send?”. Oh, the signature could accept args as well.

Nice!

‘send?’ would be nice.

take a look at .andand http://weblog.raganwald.com/2008/01/objectandand-objectme-in-ruby.html though renaming it ._? might be nicer # almost equivalent to groovy’s object.?.method

+1 for send?

How about `attempt?`? Try reminds me of `try… catch`

`person.attempt?(:name)`

+1 for “send?”.

I like the name try, though I prefer a version that allows arguments and/or a block: http://gist.github.com/26751

Try is fine by me, but +1 for nakajima’s patch.

I particularly like the use of the symbol :wee in his examples.

why not use a proxy so you could just do string.try.size ?

-5 for send?. Foo? methods, by convention, return boolean values. Try does not.

+1 nakajima

josegit: That’s usually the case, but not always. To quote matz from a recent ruby-talk thread:

By convention, they are predicates, which means the return value can be considered as boolean value. But at the same time, the values are not limited to true and false. For example, defined? returns the string to describe the kind of expression defined, and nil otherwise.

There’s another convention that when a predicate returns non-true value for represent true, it should return nil for false.

Then again, whether this is a predicate can be discussed. I think I’ll retract my +1 for a ±0.

Mangled by textile. First and last paragraphs are mine, middle two are quoted from matz.

A better example may be Ruby’s Numeric#nonzero? which returns the number if it’s not zero and returns nil otherwise. send? would be pretty analogous.

I’ll let others hash out the appropriate method name, but I agree that it should at least support arguments like #send.

Please submit patches at Lighthouse and assign to me.

Thanks!

this is nice sugar.

Sumitted patch with Nakajima’s suggestion: http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1425-allow-optional-arguments-andor-block-for-objecttry

Submitted a patch based on alloy’s, adding the option of doing person.try_name(arg1, arg2, ...) { ... }

http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1425-allow-optional-arguments-andor-block-for-objecttry

Thank you very-very much. I think it will be very useful!

Surely with nakajima’s version it should be called do_or_do_not – remember “there is no try”...

The problem is nil.respond_to?(:id) is true. and so you can’t use it as for @object.try.id

vitaly: That’s an instance in which you’d probably want to rethink using #try anyway, and instead perhaps structure your interface in such a way that doesn’t return nil objects.

I know it’s ridiculous for me to say this, since I was the one who recommended an “improved” version, but I actually think that nine times out of ten, using #try is a code smell.

noticed a problem.

“some string”.try(:gsub, “some”, “this”) => “this string”

nil.try(:gsub, “some”, “this”) => TypeError: $_ value need to be String (nil given) from (irb):18:in `gsub’ from (irb):18:in `send’ from (irb):18 from :0

This is because nil defines a private method “gsub”. Is there really a need for “try” to “try” private methods? It seems like a less useful case than someone using gsub against an accidental nil.

+1 nakajima

nakajima suggestion is already into core:

http://github.com/rails/rails/commit/823b623fe2de8846c37aa13250010809ac940b57