Monkey patch

The term monkey patch seems to have come from an earlier term, guerrilla patch, which referred to changing code sneakily – and possibly incompatibly with other such patches – at runtime.[1] The word guerrilla, homophonous with gorilla (or nearly so), became monkey, possibly to make the patch sound less intimidating.[1] An alternative etymology is that it refers to “monkeying about” with the code (messing with it).

Despite the name's suggestion, the "monkey patch" is sometimes the official method of extending a program. For example, web browsers such as Firefox and Internet Explorer used to encourage this, although modern browsers (including Firefox) now have an official extensions system.

The definition of the term varies depending upon the community using it. In Ruby,[2] Python,[3] and many other dynamic programming languages, 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 desired. 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.

Monkey patching is used to:

• Replace methods / classes / 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 the result of a patch at runtime to the state 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);
• Explore different automated fixes to provide self-healing.[4]

Malicious, incompetently written, and/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; a new release may very well break the patch. For this reason monkey patches are often made conditional, and only applied if appropriate.[5]
• 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 monkey patches are written with a pattern like alias_method_chain.[6]
• They create a discrepancy between the original source code and the observed behaviour that can be very confusing to anyone unaware of the existence of the patch. For example, the Linux kernel detects proprietary and other third-party modules such as the Nvidia driver, which tamper with kernel structures, so that developers will not waste their time trying to debug a problem that they cannot fix.[7]
• They can be written with malicious code in order to attack the main program, or each other. As an example, in 2009, Giorgio Maone, developer of NoScript, attacked the Adblock Plus extension for Firefox, adding exceptions so that advertisements on his own websites would work. The offending code also made sure that if the user attempted to remove the exceptions, they would be added again. The spat caused widespread anger, leading to a back and forth war between new adblock rules being pushed to users, followed by Maone sabotaging the new ones, which eventually led to Mozilla stepping in to change policies regarding add-ons.[8]

The following Python example monkey-patches the value of Pi from the standard Python math library to make it compliant with the Indiana Pi Bill.

>>> import math
>>> math.pi
3.141592653589793
>>> math.pi = 3.2   # monkey-patch the value of Pi in the math module
>>> math.pi
3.2
================================ RESTART ================================
>>> import math
>>> math.pi
3.141592653589793
>>>

Wikiquote has quotations related to: Monkey patch

• Aspect-oriented programming
• Category in Objective-C
• Dynamic loading
• Extension method in C#
• Self-modifying code