[ruby-core:22309] Re: [Feature #1122] request for: Object#try

>> Chaining would go like this then?
>>
>> x.if_not_nil.do_foo.if_not_nil.do_bar
>>
>> We'd have to repeat #if_not_nil at each link in the chain, and it would
>> become ambiguous whether the second #if_not_nil was intended to handle
>> x==nil or x.do_foo==nil (or both).
>>
>> Or maybe the method_missing implementation should return self? Then we could
>> write:
>>
>> x.if_not_nil.do_foo.do_bar
>>
>> Then if you explicitly want to handle a nil result from do_foo, you could do
>> so unambiguously:
>>
>> x.if_not_nil.do_foo.if_not_nil.do_bar

Yeah chaining them would...still not be an option.  I
Here was David Blacks' thought on chaining [previous in the thread]

"They're not really sub, though; they're just further messages. I think
if you have a whole bunch of things you might want to do with an
object conditionally, it's best to set up an if statement. Otherwise
it all gets very magic-dot-ish and obscure."

I was forced to somewhat agree :)

One attempt at chaining exists [2] but [as is evident] it seems mostly
a joke.  I had thought that we could return a child class of nil
instead of nil when try fails, but maybe that would be unstable if
people are mixing normal nil objects with  something like

TryFailure < Nilclass; end


> I think you are off the track here, at least WRT the original use of try.
>
> The #try(:name,...) would try to call :name on the object, and return
> nil (rather than an exception) when the object does not respond to the
> method (or in the case of Rails it does not have the requested
> attribute).

[2] comment 7 mentions this slightly--"Reg[inald Braithwaite]'s
assertion that 'both responds_to? and unless nil are legitimate
interpretations of' 'try' underlies the difficulty in establishing
semantics for new idioms." So I do like responds_to but it would also
not close the door on its meaning or implementation yet.

Also don't we want to allow it to handle method_missing method
creation semantics?  That's why my preference is to have two
functions: [for example] if_not_nil and if_respond_to to avoid
confusion.  There may be a way to get something that does both,
however, like [from previous post by Ondrej Bilka]

foo.?bar should be same as (foo.bar rescue NoMethodError)

maybe?
Except on second thought this allows you to call methods from nil
itself, which is probably unexpected.


> The other thing I occasionally do and which could be more streamlined
> looks like this:
>
> here fd of a pipe might be already closed but it may not
>
>  fd.close rescue nil # hopefully prevents zombie hordes
>
> assume Object#quiet returns an object that does not raise an exception:
>
>  fd.quiet.close # hopefully prevent zombie hordes

That is interesting [but how does it know which exception to
swallow--assume StandardError? what if the exception raised isn't
quite the expected one? ] :)

> Much simpler condition here
>
>  glob = Dir.glob input + File::Separator + "*" + $IN_EXT if
> File.quiet.directory? input

indeed looks simpler.

Finally, here's another few try naming options

foo.if.bar
foo.if?.bar
foo.respond?.bar
foo.not_nil?.bar
# or steal one from edge rails, and redefine what it does
foo.present.bar
ok those might be bad ideas

If you can't tell I'm still basically fighting for some way to get
andand into the core--it is just so useful, even if named something
else.

Thanks!
-=r
[1] http://chalain.livejournal.com/66798.html
[2] http://blog.lawrencepit.com/2009/01/11/try-as-you-might/