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?

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| renunciation is not getting rid of the things of this world, but accepting
| that they pass away. --aitken roshi
===============================================================================