From: Austin Ziegler Date: 2005-05-07T02:34:06+09:00 Subject: Re: RCR 303: nil should accept missing methods and return nil On 5/6/05, Jim Weirich wrote: > 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. Not really. The precise example I gave is a bad one. But generally, if I'm calling #do_something, it's because I want something done. If I have a nil object instead, then I have a problem -- and I want to know it as early as possible. I've emphasized this in both fora, but there have been some problems during the redevelopment of PDF::Writer that *would* have been masked by this sort of behaviour, resulting in bad output. If I had this, then I would have to comb through the bad output to find the problem. This is difficult when the fault might be literally hundreds (or thousands) of lines away from what generates the error. If I say #do_something and have a nil object, this proposal merely masks the problem -- that I got a nil object to operate on. If what I'm using is never supposed to return nil, but did anyway, this is definitely wrong. (And yes, I have had *exactly this problem*. No, I can't show you the code -- I fixed the problem and the code doesn't exist anywhere at this point.) For a very small class of problems, this will work. For anything that has to interact outside of the Ruby program in question, this is -- and always will be -- a disaster. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca