Look, what is so innately wrong with monkey-patching? You mention it in a distinctly perjorative tone, but why? Yes it can be used badly, but it can also be bloody brilliant.
Bad monkey-patching: touching any method defined in core.
Good monkey-patching:
class Array
def to_sentence
return "I contain #{self[0..-2].map {|x| x.to_s + ', '}}and #{self[-1]}."
end
end
Seriously, being able to do throw that kind of thing into the beginning of your program, extend the core classes just like that, is frickin' awesome.
People abuse it, yes, like people abuse any power they're given. Just last week I wasted several hours trying to fix some strange ActiveRecord errors which turned out to be the morons in Rails Core monkeypatching Hash#to_json; my solution ended up being monkeypatching it straight back. Great. Obviously, I wish I didn't have to do that kind of thing.
However - don't blame the technique, blame the people who misuse it. Used properly, it can be a dream come true. Always wish that Time could print to string including milliseconds? Baby, I've got Time#to_s_usecs for you in three lines of code.
Monkeypatching is a sharp knife - you can cut your bread or you can cut yourself. Either way, it's not the knife's fault. And either way, I'd rather have a knife than not have one : )
The problem is that you throw this in your module, and then someone else defines another Array#to_sentence (say in some Natural Language module you require) and all of a sudden you've got hell on earth.
This is fine if this will be only used by you. Now what if you started distributing this, say in a gem? The person using your software may already have a to_sentence monkey-patch in place, and your gem they are using interferes with that.
Also, what if someone monkey-patches a core method of Array? Any one else consuming this script has a broken build they need to deal with it. Most of the time, these collisions do not occur, but sometimes they do and and often in subtly and hard-to-detect ways.
Overriding core methods is a definite no-no. And if you were actually going to distribute something, you'd probably have a new class descending from Array and add your methods to that.
But for private code - you've got a bunch of Arrays, you want them to output something interesting - what's wrong with that?
Look, what is so innately wrong with monkey-patching? You mention it in a distinctly perjorative tone, but why? Yes it can be used badly, but it can also be bloody brilliant.
Bad monkey-patching: touching any method defined in core.
Good monkey-patching:
Seriously, being able to do throw that kind of thing into the beginning of your program, extend the core classes just like that, is frickin' awesome.People abuse it, yes, like people abuse any power they're given. Just last week I wasted several hours trying to fix some strange ActiveRecord errors which turned out to be the morons in Rails Core monkeypatching Hash#to_json; my solution ended up being monkeypatching it straight back. Great. Obviously, I wish I didn't have to do that kind of thing.
However - don't blame the technique, blame the people who misuse it. Used properly, it can be a dream come true. Always wish that Time could print to string including milliseconds? Baby, I've got Time#to_s_usecs for you in three lines of code.
Monkeypatching is a sharp knife - you can cut your bread or you can cut yourself. Either way, it's not the knife's fault. And either way, I'd rather have a knife than not have one : )