From: mark sparshatt <msparshatt@...>
Date: 2005-02-22T05:58:39+09:00
Subject: Re: destructive! operations

ES wrote:


> I suppose the question is, then, is it necessary to have the above behaviour?
> As I understood it, the desired functionality was something like (my syntax):
> 
>  ob.not_nil?.do_something
> 
> Conceptually expands to:
> 
>  ob.do_something unless ob.nil?
> 
> For this purpose, it should be sufficient to add a method to both Object
> and NilClass. NilClass could then return an object that simply consumes
> all methods fed to it and propagates itself after each call, like was
> described in the original post as far as I can recall its contents. This
> behaviour would then not be accessible except when using NilClass#not_nil?
> so it wouldn't cause problems in other conditionals. Is there a use case
> where this would cause a problem, or why is it desirable that the explicit
> comparison be allowed for the special NIL and not just the chaining?
> 
> Again, sorry if this has already been covered; feel free not to reply,
> I'll read the NG in the evening. I'm just bored at work :)
> 
> 

The problem with this solution is the new object won't behave like nil 
in an if expression

if ob.not_nil?.do_something
   code
end

would run the code when obj is nil

There seems to be 2 requirements
the nil object shouldn't be changed, in order to not hide any errors
the new nil object should behave like nil when tested

that's why it can't be done in pure ruby

--
Mark Sparshatt