Monkey patch

From Wikipedia, the free encyclopedia

This article does not cite any references or sources. (September 2006)
Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

A monkey patch (also spelled monkey-patch, MonkeyPatch) is a way to extend or modify the runtime code of dynamic languages (e.g. Smalltalk, Javascript, Ruby, Perl, and Python) without altering the original source code.

This process is also referred to as:

Guerrilla patching
Extending previously declared classes
Reopening classes
Hijacking
Duck Punching
Method Swizzling

1 Etymology
2 Applications
3 Pitfalls
4 See also
5 External links

[edit] Etymology

The term monkey patch was first used as guerrilla patch, which referred to changing code sneakily at runtime without any rules. In Zope 2 these patches would sometimes interact counterintuitively, which was referred to as the patches engaging in battle with each other.

Because the word guerrilla and gorilla sound so similar people started using the incorrect term gorilla patch instead of guerrilla patch. When a developer then created a guerrilla patch they tried very hard to avoid any battles that may ensue due to the patch and the term monkey patch was coined to make the patch sound less forceful.[1]

The term monkey patch caught on and has been in use ever since. The definition of the term varies depending upon the community using it.

In Python, the term monkey patch only refers to dynamic modifications of a class at runtime based on the intent to patch existing methods in an external class as a workaround to a bug or feature which does not act as you desire. Other forms of modifying a class at runtime have different names, based on their different intents. For example, in Zope and Plone, security patches are often delivered using dynamic class modification, but they are called hot fixes.

In Ruby, the term monkey patch was misunderstood to mean any dynamic modification to a class and is often used as a synonym for dynamically modifying any class at runtime.

Some members in the Ruby world started adopting the term duck punching in lieu of monkey patching.[2] This term comes from the extensive use of duck typing in Ruby and Python as explained by Adam Keys and Patrick Ewing at RailsConf 2007:

Way down in Dallas, in the Dallas Ruby Brigade, we believe that monkey-patching, while it’s served us well, the time has come for some new terminology there. So while you have duck-typing in Ruby, we believe that monkey-patching should become duck-punching.

– Adam Keys

Well, I was just totally sold by Adam, the idea being that if it walks like a duck and talks like a duck, it’s a duck, right? So if this duck is not giving you the noise that you want, you’ve got to just punch that duck until it returns what you expect.

– Patrick Ewing

[edit] Applications

Monkey patching is used to:

Replace methods/attributes/functions at runtime;
Modify/extend behaviour of a third-party product without maintaining a private copy of the source code;
Apply a patch at runtime to the objects in memory, instead of the source code on disk;
Distribute security or behavioural fixes that live alongside the original source code (an example of this would be distributing the fix as a plugin for the Ruby on Rails platform).

[edit] Pitfalls

Using a monkey patch can lead to the following problems:

If the product you have changed changes with a new release it may very well break your patch.
If two modules attempt to monkey-patch the same method, one of them (whichever one runs last) "wins" and the other patch has no effect. (unless monkeypatches are written with pattern like alias_method_chain)
It creates a discrepancy between the original source code on disk and the observed behaviour that can be very confusing when troubleshooting, especially for anyone other than the monkey patch author.
A monkey patch can lead to upgrade problems when the patch makes assumptions about the patched object that are no longer true.