On Aug 10, 2005, at 2:06 PM, basi wrote:

> Thanks all for the suggestions. This solution appeals to me because I
> don't have to define anything new. I wonder if, in general, this is a
> good criteria for evaluating solutions.

My two cents:

Ruby makes it trivially easy to alter the behavior of the core  
classes.  It's a powerful feature and I love it, but it's also easy  
to abuse.

If you're working on a Domain Specific Language and want to alter the  
core classes to fit that model, I say go for it.  If you can add a  
few methods to Array or String or whatever to help with the task you  
are currently tackling, again I say do it.

However, I'm usually against hacks to change the behavior of the core  
classes.  You could break a lot of code that way, possibly in Ruby's  
rich standard library.  Plus, your teaching yourself to rely on non- 
core techniques, which I doubt will help in the long run.  Put in  
terms of this thread, I'm fine with Rails' blank() method (just  
adding some functionality), but leery of adding empty?() to nil  
(that's not how Ruby's nil works).

Again though, that's all just my opinion.  Obviously, Ruby allows  
people to add empty?() to nil and some do.

James Edward Gray II