On Aug 10, 2005, at 1:17 PM, James Edward Gray II wrote:
> 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.
[snip]
> 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.
[snip]

This has been the biggest 'gotcha' for me; I started out with Ruby  
and slowly grew my own library of really convenient (to me) additions/ 
changes to the core libraries. Invariably, I get to a point in my  
code where I want to release it, and I'm left with three choices:

a) Require people to include my library-of-hacks (in whole, since I  
don't have it broken into tiny pieces) if they want to use my sweet  
new library I'm releasing. Not a nice dependency.

b) Copy/paste the salient hacks into my library file so they go along  
together. Ugh, now I have a version control problem.

c) Rewrite my library not to use my own hacks, but instead strive to  
use only built-in stuff.

Usually, I choose (c).


If you're doing programs just for yourself, I personally suggest you  
do whatever makes your life easier. But the addiction to customizing  
the language can be problematic if you want to share your code.