From: Daniel DeLorme <dan-ml@...42.com>
Date: 2007-07-21T14:13:08+09:00
Subject: Re: RCR? Added syntax for chains that possibly return nil

Stefan Rusterholz wrote:
> Trans wrote:
>> Sure. I realize. I'm only pointing out that this -> operator is
>> equivalent to a rescue NoMethodError,
> 
> So how can I explain to you that it *isn't*?

rescue NoMethodError has the same disadvantage as rescue StandardError; 
it may catch errors that you did not intend to. e.g.:

foo = Object.new
def foo.bar
   baz()
end

foo.bar->boo
=> NoMethodError: undefined method `baz'

begin
   foo.bar.boo
rescue NoMethodError
end
=> nil

>> Another possibility... perhaps we can add a feature to #tap (which has
>> already been added to Ruby 1.9) so that:
> 
> Somebody else here on the list uses a method 'ergo' to do what -> would 

That would be me

> do. Similar disadvantages as the ._methods solution.

except with less namespace pollution :-P

I have to admit the -> keyword would be better. With ergo I have to 
propagate the check to every step of the call chain:
   a.b.ergo.c.ergo.d.ergo.e
where -> would allow a simple
   a.b->c.d.e
(assuming that you only want to guard against b being nil)

But since other languages (e.g. PHP) use -> for method access, I think 
we would see a lot of newbies blindly using -> for all method calls and 
then wondering why things go awry. Maybe ".?" would be better? Or maybe 
we're over-thinking and this feature isn't really used often enough to 
warrant its own operator and a more verbose form like ergo is enough...

Daniel