From: Eric Mahurin <eric.mahurin@...>
Date: 2008-02-25T13:57:18+09:00
Subject: Re: Monkeypatching is Destroying Ruby

------=_Part_8739_20255606.1203915445165
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Feb 24, 2008 at 10:02 PM, James Gray <james@grayproductions.net>
wrote:

> On Feb 23, 2008, at 4:23 PM, Eric Mahurin wrote:
>
> > On Sat, Feb 23, 2008 at 3:07 PM, Avdi Grimm <avdi@avdi.org> wrote:
> >
> >> Hi folks,
> >>
> >> I wrote a blog post with the intentionally provocative title above,
> >> which can be found here:
> >>
> >> http://avdi.org/devblog/?p=18
> >>
> >
> > I don't agree with the title, but I agree almost everything you said.
>
> I'm strongly feel that James Britt has the right idea about this one.
> We should view it as just another tool to be used where it works best
> and I feel there are such places.
>
> Assigning blame to a particular element of a programming language
> seems foolish to me.  I'm pretty confident I can write some code that
> abuses the heck out of while loops.  Should we start hating those now
> too?


I don't think all language features are created equal.  Some are more
dangerous than others.  I think global variables are universally agreed to
be dangerous (in all languages), but most languages still support them
because they still can be useful.  I believe monkey patching falls into the
same category.  I think the point of this blog was to discourage people from
using it because it is dangerous.  There are simple alternatives.

> * adding #to_* methods to String.
>
> FasterCSV adds a to_csv() method to Array.  What's that likely to
> conflict with exactly?  Other CSV libraries is the only thing I can
> think of.  I can live with that.


I don't see the big advantage of Array#to_csv over a more traditional
CSV::from_a(arr), other than a few more characters to type.  It is much more
encapsulated.  The disadvantage of making Array#to_csv is that you are
modifying a global "variable" (the Array class).

> I usually only do monkey patching in the
> > following cases which have no reuse: top-level script, testing, and
> > quick hacking.
>
> I think it's the ideal tool for adding compatibility methods.  Say you
> want to write some code that works in Ruby 1.8 and 1.9, for example.
> You can add the methods you need from 1.9 to 1.8 classes, with checks
> to ensure they are only added if they don't exist already.  I can't
> think of a better solution than that.
>

Agreed.  I also think this is an appropriate application of monkey
patching.  I've done this myself too (maybe in a quiz).  But, if this is in
a large system, you wouldn't want each package to do the same patching.  It
would be best to separate the monkey patching and apply it at the top-level.

Eric

------=_Part_8739_20255606.1203915445165--