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.