From: Saynatkari <ruby-ml@...>
Date: 2005-05-07T00:08:56+09:00
Subject: Re: RCR 303: nil should accept missing methods and return nil

Ara.T.Howard@noaa.gov wrote:
> On Fri, 6 May 2005, Yukihiro Matsumoto wrote:
> 
>> Hi,
>>
>> In message "Re: RCR 303: nil should accept missing methods and return 
>> nil"
>>    on Fri, 6 May 2005 12:51:00 +0900, John Carter 
>> <john.carter@tait.co.nz> writes:
>>
>> |Be careful about exactly what is being asked for and what has been done
>> |before. I once developed an OOP system were all objects would respond to
>> |all undefined messages by doing nothing. I rapidly changed that to an
>> |error condition as in that case the complaint that it hid bugs was 
>> valid.
>>
>> I know Objective-C's nil works like that.  I once developed an OOP
>> system (which was an early version of Ruby) where nil would respond to
>> all undefined messages by doing nothing.  In production code, it does
>> nothing bad, since any production code should not raise an exception.
>> Rather it introduces new scheme of error handling.
>>
>> But during development, it can hide bugs.  It is very difficult to
>> distinguish correct error handling by ignoring unknown message, and
>> uncontrolled unintentional misbehavior caused by bugs.  It's against
>> the principle of "early death".
>>
>> Your proposal worth something, I think.  But it's not going to be seen
>> in the near future of Ruby.
> 
> 
> perhaps
> 
>   nil.blackhole = true
> 
> to change nil's behaviour.  that way it could be changed in production 
> code?

Well, there is already $DEBUG. I think that should work fine, in case
this proposal were accepted.

> -a

E

-- 
template<typename duck>
void quack(duck& d) { d.quack(); }