From: "David A. Black" Date: 2009-02-08T19:58:18+09:00 Subject: [ruby-core:21932] Re: [Feature #1122] request for: Object#try Hi-- On Sun, 8 Feb 2009, Yusuke ENDOH wrote: > Hi, > > 2009/2/7 David A. Black : >> Hi -- >> >> On Sat, 7 Feb 2009, Yusuke ENDOH wrote: >> >>> Hi, >>> >>> 2009/2/7 Narihiro Nakamura : >>>> >>>> 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. > > > I don't expect that we will do it *back and forth*, but I think > that *forth* will often be needed. I think in most cases you'd know whether you're going to do this before you start, so you would rarely have to change it. > In addition, I feel that the two styles are oddly different in > spite of almost the same meanings. > It is allowable for Object#send because there is no other way > and such a reflection feature is not so often used. But, try > will be routinely used, and thus should not emulate such a odd > style unless it really has to. > >> 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. > > > Hmm... > > > BTW, some time ago, if I'm correct, nobu suggested a new syntax: > > foo.?bar(baz) > > as a syntax sugar to: > > foo.respond?(:bar) ? foo.bar(baz) : nil > > . > I prefer it too. What do you think about it? It's a bit punctuation-heavy but I think it's preferable. Of course the whole thing leaves the question of how to handle ambiguous nils (getting nil and not knowing whether it's because there was no method or because the method returned nil). Several years ago I tried to explore the idea of a "NOACK" response, which was not nil and not an exception but which meant the object didn't know how to handle the message. But that didn't work, because how do you know whether or not to raise an exception? (I'm still interested if anyone has figured out a way to do it.) 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!