Bill Atkins wrote:
> This isn't about changing programming habits.  Having nil return nil
> for missing methods can have serious consequences.
> 
> Consider:
> 
>    file = create_new_log_file
>    file.log "here's a bit of information"
> 
> You're expecting this code to log something to a file every time it
> gets called.  But suppose create_new_log_file returns nil, due to some
> mistake you've made while coding it.  No exception is raised, so when
> you run your program, it performs its job appropriately.  You move on.
> 
> Two months later, you urgently need to get information from those
> logs.  But uh-oh - the log files are empty.  Now you're screwed.

When I see code samples arguing in favor of the status quo, I tend to 
think, But you only code it like that because you have certain 
expectations regarding nil.

And I think a good part of the argument for changing the current 
behavior is that, assuming one is cognizant of the new nil behavior, 
people will stop writing code that expects nil to yell at them.  (Though 
that doesn't address legacy code.  Ignore that for the moment.)


However, even assuming a magic wand that instantly grants each coder 
sparkling insight into the new behavior, I have a hard time seeing the 
overall benefit.

Given the above example, how would one code it with new-style nil?
Explicitly test for nil-ness? Too fugly.

Given Ruby's nature, one might have to test every object on every call, 
because who knows what might be touching it and inadvertently setting it 
to nil.

For more interesting and useful would be to solve the threading issue 
with using nil.blackhole = true inside of blocks or methods where that 
behavior is an overall win.

James