-
Notifications
You must be signed in to change notification settings - Fork 21.7k
Commit
…s Wanstrath]
- Loading branch information
There are no files selected for viewing
27 comments
on commit 5173079
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
‘send?’ would be nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for send?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about `attempt?`? Try reminds me of `try… catch`
`person.attempt?(:name)`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for “send?”.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the name try, though I prefer a version that allows arguments and/or a block: http://gist.github.com/26751
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try is fine by me, but +1 for nakajima’s patch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I particularly like the use of the symbol :wee in his examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not use a proxy so you could just do string.try.size ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-5 for send?. Foo? methods, by convention, return boolean values. Try does not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 nakajima
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mangled by textile. First and last paragraphs are mine, middle two are quoted from matz.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’ll let others hash out the appropriate method name, but I agree that it should at least support arguments like #send.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please submit patches at Lighthouse and assign to me.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is nice sugar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sumitted patch with Nakajima’s suggestion: http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1425-allow-optional-arguments-andor-block-for-objecttry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very-very much. I think it will be very useful!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surely with nakajima’s version it should be called do_or_do_not – remember “there is no try”…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is nil.respond_to?(:id) is true. and so you can’t use it as for @object.try.id
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 nakajima
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nakajima suggestion is already into core:
http://github.com/rails/rails/commit/823b623fe2de8846c37aa13250010809ac940b57
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.