From: Michal Suchanek <hramrach@...>
Date: 2009-02-08T13:23:32+09:00
Subject: [ruby-core:21924] Re: [Feature #1122] request for: Object#try

On 08/02/2009, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
> Hi,
>
>  2009/2/7 David A. Black <dblack@rubypal.com>:
>
> > 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.
>
>
>
> I don't expect that we will do it *back and forth*, but I think
>  that *forth* will often be needed.
>
>  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.
>
>
>
>  >> 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.
>
>
>
> 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?
>

That looks pretty good except it would need parser changes, and would
possibly make method names previously valid into invalid ones.

You could probably change the interface to make it possible to do
something like:

foo.try_method(:bar).call(baz) which allows calling with the same argument list.

If the method does not exist it should obviously return a method that
just junks any arguments given.

It's much longer than

foo.try(:bar,baz)

but it makes it clear *what* is tried. It also makes it clear what is
rescued in a more complex expression avoiding the "rescue nil"
catching exceptions that were not expected.

However, it does not help the rails case at all because the intended use is

foo.try(:name)

with no arguments which expands into

foo.try_method(:name).call()

.. way too long for the simple case with no arguments.


However, I often get expressions where this does not help - the
problem is I do some actual arithmetic operation which fails if one
argument is nil.

I should scan my code for these because I am not sure if something like

"a".quiet + foo

would help much - how many "quiet" I would need for this to work in a
typical case.

Thanks

Michal