On Mon, 9 May 2005, 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. You confirm what I am saying about the difference between "uninitialized and "no thing here". There should be an explicit difference. Such a mistake you have presented would typically fill "file" with "uninitialized", and invoking the log method on "uninitialized" should throw an exception. On the other hand, a nifty way of deliberately switching off logging, without changing a line of the client code would be to stuff "No thing here" into file, resulting in no thing happening. That is why I have now withdrawn my RCR, and are working instead on an implementation of the Nothing class, leaving "nil" to mean "uninitialized". It's coming along very nicely thank you, the only sorrow I have at the moment is to be able to do what I used to with nil takes a bit more typing.... may_be_nothing = nil if may_be_nothing definitely_isnt_nothing( may_be_nothing) end now becomes... may_be_nothing = Nothing.new # I love that unless may_be_nothing.nothing? definitely_isnt_nothing( may_be_nothing) end ie. "nil" is a Special object in ruby, and the code for handling "if" statements knows about it. (The RTEST macro in ruby.h) But hopefully the change conditional to virtual method refactoring will make most of those instances go away. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter / tait.co.nz New Zealand Surprisingly enough, this email does not originate from a beetle.