Sylvain Abélard
3/21/2007 1:18:00 PM
> 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.