From: Gary Wright <gwtmp01@...>
Date: 2008-03-01T01:46:50+09:00
Subject: Re: Monkeypatching is Destroying Ruby


On Feb 29, 2008, at 11:08 AM, Florian Gilcher wrote:
> Extending the Core-Classes is not dangerous//bad. It just requires  
> care. If Matz and Co. decide to add functionality to core classes,  
> they are not monkey-patching. Usually, this change is well  
> documented in a changelog that should be read if you update the  
> language to a new major version.


Let me avoid the phrase 'monkey-patching' for the moment.

If you imagined a version of Ruby that did not permit
local additions to core classes then the only source
of change to those classes would be the evolution of
the language itself.  But since that isn't the case,
core classes can acquire new methods in several ways:
-- new release of Ruby
-- local additions in a code base I manage
-- 'foreign' additions in a gem or other dependency

It pretty much doesn't matter where the conflicting
change originated, it is still a problem, if you
want to integrate the code bases.

I can read the release notes/code of the Ruby
distribution or I can read the documentation/code
of a gem that I'm dependent on but the end result
is the same: a conflict that has to be resolved.

If you want to say that changes that originate from
Matz are 'blessed' and not 'monkey-patching' fine but
that doesn't change the fact that I've still got
a conflict that has to be resolved.

Of course I could point out that this isn't just a
problem with conflicting method names in core classes.
It is possible to have conflicts in the class/module
namespace also.

So I believe the problem is a much more general one of
how to manage the composition (i.e. integration) of
independently evolving distributed code bases.  The
'monkey-patching' is bad school of thought is basically
an argument to localize all evolution of the libraries
and language in some sort of central standards committee.
No doubt that would work, but it has its own set of
problems.

Gary Wright