I tried to understand the monkey-patch concept. I drove into that gem:
http://blog.nicksieger.com/articles/2008/03/14/monkey-patching-is-part-of-the-diy-culture
Excerpts (bold text is by my own decision) :
So, it took me a while before it occurred to me that something in my project might be overriding make_tmpname. But even after I found it, notified MenTaLguY, and he fixed it, it still left me wondering: who’s in the wrong here? Akira-san, for not making a better way to hook into make_tmpname, Rick for monkey-patching it, or MenTaLguY for changing the method arity in his rewrite? I can’t really point the blame at any of them.
There are certainly more egregious and offensive monkey-patches than this example (and I include myself in that camp). In any case though, I could live with just about any monkey-patch if I had better debugging tools. For example, it would be great if you could ask Ruby to track and retain references to all methods, including those that get replaced, along with the source locations where each was defined. Another possibility might be a before_method_added hook that could let you track method replacements as they’re about to happen (and maybe even veto method redefinitions!).
Yeah, and why not veto the veto, and allowing some other code to veto that also :-)
You can't point the blame? The blame is to consider monkey patching a valid programming practice! If you want to be able to veto method definition, or need debugging methods to track the changes, maybe there is something wrong with the concept...
Think of it: he even considers that the guy who changed a private method could be the one to blame :-)
Incredible! Everyone with common sense agrees that statefulness is evil, and these guys try to add yet more state to try to control the state. And we have to trust them to build secure software?