Monkey patch

A monkey patch is a way to extend or modify the run-time code of dynamic languages without altering the original source code. This process has also been described as "duck punching".^[1]

Etymology

The term monkey patch seems to have come from an earlier term, guerrilla patch, which referred to changing code sneakily at runtime. The word guerrilla, homophonous with gorilla, became monkey, possibly to make the patch sound less intimidating.^[2]

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 or module at runtime, motivated by the intent to patch existing third-party code as a workaround to a bug or feature which does not act as you desire.^{[citation needed]} Other forms of modifying classes 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.^{[citation needed]}

In Ruby, the term monkey patch means any dynamic modification to a class and is often used as a synonym for dynamically modifying any class at runtime.^{[citation needed]}

Some members in the Ruby world started adopting the term duck punching in lieu of monkey patching, originating from the extensive use of duck typing in Ruby and Python.

Applications

Monkey patching is used to:

• Replace methods/attributes/functions at runtime, e.g. to stub out a function during testing;
• 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).

Pitfalls

Carelessly written or poorly documented monkey patches can lead to problems:

• They can lead to upgrade problems when the patch makes assumptions about the patched object that are no longer true; if the product you have changed changes with a new release it may very well break your patch. For this reason monkey patches are often made conditional, and only applied if appropriate^[3].
• 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 a pattern like alias_method_chain^[4].
• They create a discrepancy between the original source code on disk and the observed behaviour that can be very confusing to anyone unaware of the patches' existence.

Even if monkey patching isn't used, some see a problem with the availability of the feature, since the ability to use monkey patching in a programming language is incompatible with enforcing strong encapsulation, as required by the object-capability model, between objects.

See also

• Self-modifying code
• Scratch monkey

References

1. ^ Delabar, Eric (2008-05-02). "Duck Punching JavaScript - Metaprogramming with Prototype". http://www.ericdelabar.com/2008/05/metaprogramming-javascript.html. Retrieved 2008-07-03. 
2. ^ Limi, Alexander; Shane Hathaway (2005-12-23). "Monkey patch". Plone Foundation. http://plone.org/documentation/glossary/monkeypatch. Retrieved 2008-07-03. 
3. ^ "Maintainable JavaScript: Don’t modify objects you don’t own". 2010-03-02. http://www.nczonline.net/blog/2010/03/02/maintainable-javascript-dont-modify-objects-you-down-own/. 
4. ^ "New in Rails: Module#alias_method_chain". 2006-04-26. http://weblog.rubyonrails.org/2006/4/26/new-in-rails-module-alias_method_chain.