From: "David A. Black" <dblack@...>
Date: 2009-02-07T23:41:07+09:00
Subject: [ruby-core:21909] Re: [Feature #1122] request for: Object#try

Hi --

On Sat, 7 Feb 2009, Yusuke ENDOH wrote:

> Hi,
>
> 2009/2/7 Narihiro Nakamura <redmine@ruby-lang.org>:
>> Feature #1122: request for: Object#try
>> http://redmine.ruby-lang.org/issues/show/1122
>>
>> Author: Narihiro Nakamura
>> Status: Open, Priority: Normal
>>
>> Hi.
>>
>> Object#try is new feature of rails2.3.
>>
>> http://guides.rubyonrails.org/2_3_release_notes.html
>> http://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/try.rb
>> http://ozmm.org/posts/try.html
>>
>> Matz said: "OK, good name is the last problem."
>>
>> Anyone has better name?
>
>
> Interesting.  I think `try' is good enough for me as non-native.
>
> But why does it take Object#send-like interface?
> I dislike Object#send because complex modifications are needed:
>
>  foo.bar(baz) -> foo.send(:bar, baz)
>
> I have to type "send(:", move the cursor, delete "(", and type ", ".
> What a pain!
>
>
> Of course, it can't be helped in the case of Object#send.
> But there is no reason for Object#try to follow it.
> I prefer:
>
>  foo.bar(baz) -> foo.try.bar(baz)
>
> because it is much simpler (only to insert ".try")

I don't think that's a big issue, because you'd probably either use
try or not, and not change it back and forth.

> For example:
>
>  x = nil; p x.try + 1 #=> nil
>  x = 100; p x.try + 1 #=> 101

I prefer the send-like way. "try" without an argument doesn't make
sense to me here; it leaves me asking, "Try *what*?" The idea that
"try" in the abstract means "self or a BasicObject that returns nil
for missing methods" isn't a good fit, I think.


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!