From: "Sylvain Abélard" <sylvain.abelard@...>
Date: 2007-03-21T22:17:31+09:00
Subject: Re: nil? with block

> I am not so sure.  But you can easily implement this with another method
> name so you don't have to change existing code's behavior.  Also, nil
> values might be just only one reason to throw an exception so I am not
> sure about general usefulness.

I also doubt this would ever be useful. I like 'long lines' and hate
loads of 'if-statements' but I must admit I find them useful (or at
least, any other solution looks awful to me).


Why not using, let's call them  "accessors?" which are "accessors with
a question mark".
Just by hacking with a bit of "method_missing" in both your class and
NilClass, this would not slow exec time much I guess, and the
implementation should also be trivial.

- in the class, you just send(accessor_name) when you get an unknown
accessor_name?
- in nilclass, you return "stuff" when having a '?' method (except
nil? or empty?)

The problem, IMHO, resides in the impossibility to return a coherent "stuff".
You *want* Ruby to NoMethodError you when you fail something.
You *can't* always know what you could prefer when your call fail.
Should "stuff" be nil, 0, empty string, new object ?


I suggest you use that in your project (if that's a big one) and then
tell us in a few weeks/months if that changed your life or not. If
that made your debugging harder.
Then again, this is a matter of personal preference I guess ;)

-- 
Sylvain Abelard,
Railer Rubyist. Epita MTI 2008.