freedom patching

[Caio Tiago Oliveira]

On 09/26/2014 03:35 PM, Bráulio Bhavamitra wrote:
> for those getting afraid of monkey patching: 
> http://vimeo.com/17420638#t=27m27s

I think you missed the point. He, DHH, loves monkey patching. His
point is that he should be allowed to do his monkey patching, as he
thinks he should be allowed to smoke pot or use cocaine.

You are allowed to use monkey patch. But the same way you won't inject
cocaine on other people body or put some pot on cakes you are going to
share without the others consenting, you can't just throw monkey
patching on code you share without the others consenting.

You can use monkey patching or smoke pot, as long as you don't enforce
me to monkey patch or smoke pot too.
The freedom must be present on both sides.


While I don't want to go too deep in why I dislike monkey patching, it
is not the only way of giving coders freedom. Traits is another
option: http://jsuereth.com/2010/07/13/monkey-patching-scala.html
and some design patterns can be used in a case by case basis. Think of
traits as a self documented monkey patching, which is discoverable and
you can turn it off.

DHH just mock on the design patterns uses and says "this is bad",
while he didn't use any arguments of why we should favour monkey
patching over traits.
With monkey patching you are adding a lot of effort for newcomers to
find out what your code does, because it will require inspection on
totally unrelated places. When monkey patching was much more popular
in the Rails community, getting conflicts between gems usage was quite
popular too.
You could take two nicely working plugins, but they would require
conflicting monkey patchings. Thus, this breakage from isolation would
lead to the impossibility of having both of them working in the same
environment without another serie of monkey patchings, to fix the
conflicts caused by it.

With lots of monkey patchings you are just doing all of the system
less friendly to new contributors.