From: Lionel Thiry Date: 2005-05-07T00:09:27+09:00 Subject: Re: RCR 303: nil should accept missing methods and return nil Jim Weirich a �crit : > On Friday 06 May 2005 12:07 am, Austin Ziegler wrote: > >>Right. But why should I have to make that change for just about any >>application that I end up writing? There are a lot of cases where >>nil can arise -- and if it does arise, it may be incorrect. Do you >>*want* to give me RSI by forcing me to do: >> >> foo.bar unless foo.nil? >> >>Sorry, but the current behaviour is more correct. > > > Actually, it is the current behavior that forces you to write the "unless > foo.nil?", since sending the "bar" message to nil is an error. If nil was > changed to be a message eating variant, then > > foo.bar > and > foo.bar unless foo.nil? > > would be equivalent. In other words, the change would help alleviate your RSI > problems. But, if foo wasn't supposed to be nil, what would happen? foo.bar gives nil, which would be used by other operations that each would give nil, nil, and nil again. And at the end of the chain, you don't have your expected behavior, because there was a bug. From where did the first unwanted nil come from? Where is that bug? Then, to prevent such annoying bug to happen, I suppose I'd feel forced to write this each time I suspect some foo could be nil: if $debug && foo.nil? raise "foo is nil" else foo.bar end My opinion is that: nil handling is annoying but difficult debuging is worse. > > I will admit that my gut reaction is to fall in the "should throw an > exception" camp. But the idea of a universal Null Design Pattern with nil is > intriguing. John's suggested experiment is fairly painless ... I'm willing > to try it and see if I'm persuaded. > If the initial goal of this RCR is to make the Null Design Pattern somewhat universal in ruby, what about having a new litteral like for example "null_object" that would do that job? -- Lionel Thiry Personal website: http://users.skynet.be/lthiry/