Monkey patch

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, Objective-C, Ruby, Perl, Python, Groovy etc.) without altering the original source code.

This process is also referred to as:

• Guerrilla patching
• Extending previously declared classes
• Reopening classes
• Hijacking
• Duck Punching^[1]
• Method Swizzling

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.

Since the word guerrilla and gorilla are near-homophones, 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.^[2]

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. 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:^[3]

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

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.
• 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.

References

See also

• Actionscript
• Application Enhancer
• JavaScript
• Python programming language
• Ruby programming language
• Ruby on Rails
• TiddlyWiki
• Zope
• Groovy programming Language