From: Christopher Dicely <cmdicely@...>
Date: 2008-02-25T02:57:59+09:00
Subject: Re: Monkeypatching is Destroying Ruby

On Sun, Feb 24, 2008 at 8:18 AM, Avdi Grimm <avdi@avdi.org> wrote:
> On Sun, Feb 24, 2008 at 10:36 AM, Kevin Williams <kevwil@gmail.com> wrote:
>  >  I agree with everything Avdi has said, with the caveat that James is
>  >  also right here. Use with caution, document the crap out of any
>  >  monkeypatching you do, and get on with life.
>
>  The "use with caution" part is key.  All hyperbole aside, I'm not
>  saying we should never monkey patch.  I'm just concerned when I see it
>  used by smart programmers as if it were the standard Ruby mechanism of
>  extension.

The thing is, it is *a* standard Ruby mechanism of extension, and it
may often be the simplest--for them, even when it doesn't seem to be
for you. And that's the tricky thing about simplicity; its mostly not
objective, its mostly about what matches the way a given person
thinks. The upside of Ruby's embrace of "there's more than one way to
do it" is that there is likely to be a way available that fits the way
you think fairly naturally, no matter where you come to Ruby from and
how long you've been using it (as long as you've mastered the basics).
The downside is that the most simple, direct, and natural way for
someone else to do something in Ruby may not be the most simple,
direct, and natural way for you.

That being said, the hyperbolic title aside, your blog post seems to
be largely stuff I can agree with, though I think you've misplaced the
problem very slightly. I don't think monkey patching itself is a
problem, I think the problem is that there isn't a good enough body of
experience of what to do and what not to do with monkey patching.
(Both in terms of when monkey patching is the right solution and when
there is a better alternative, and what to do and avoid doing when
you've made the decision to monkey patch.) Unlike basic composition
vs. inheritance questions, and other OOP considerations where the
facilities have been common in industrially-popular languages for
quite some time and, even if there aren't cut-and-dried standards to
apply there is a considerable body of advice and experience that most
programmer's have been exposed to, monkey patching is a lot more of a
"wild frontier" right now.

But criticism like yours is an important part of the dialogue that
needs to happen to work out where the problems are and to file the
rough edges off so that monkey patching can become a well-understood
tool that can be used effectively where it is appropriate and avoided
where it is not.