From: "Brian Schröder" <ruby.brian@...>
Date: 2005-05-07T00:43:26+09:00
Subject: Re: RCR 303: nil should accept missing methods and return nil

On 06/05/05, Ara.T.Howard@noaa.gov <Ara.T.Howard@noaa.gov> wrote:
> On Sat, 7 May 2005, Saynatkari wrote:
> 
> > 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.
> 
> not at all - $DEBUG would need to be on by defualt then and most of the time
> then and this causes reams of output on STDERR for many libs in addition to
> subtly changing their behaviour.
> 
> what i'm suggesting is a 'normal' behaviour whereby nil throws NoMethodError
> (current default) - note that this is NOT $DEBUG=true - and a built-in swith
> to turn it off
> 
>    nil.blackhole = true
> 
> or perhaps a new global
> 
>    $NIL_BLACKHOLE = true
> 
> or maybe better
> 
>    NilClass::blackhole = true
> 
> to cause nil to obey the null pattern.
> 
> this feature wouldn't affect any code now since the normal behaviour would
> remain the same.  $DEBUG is a global that affects tons of code in addition to
> the (proposed) nil mods and therefore can't be used i think.
> 
> cheers.

Wouldn't it be even simpler to include the proposed nillify.rb in the
standard and use either
require 'nillify' or 
ruby -rnillify.

Or even simpler, just include the declaration in the program?

regards,

Brian 

-- 
http://ruby.brian-schroeder.de/

multilingual _non rails_ ruby based vocabulary trainer:
http://www.vocabulaire.org/ | http://www.gloser.org/ | http://www.vokabeln.net/