application architecture article at_tecp c# code customizing development dia14 drupal duckpunching dynamic en.wikipedia.org etymology explica%C3%A7%C3%A3o_introdut%C3%B3ria hacking hacks humor jargon javascript languages mac monkeypatch monkeypatching programming python ruby slang 2008

My tags:

From Wikipedia, the free encyclopedia

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 has also been described as "duck punching". ^[1]

Contents 1 Etymology 2 Applications 3 Pitfalls 4 References 5 See also

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

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 means 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]

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, 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).

[edit] Pitfalls

Carelessly written or poorly documented monkey patches can lead to the 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.
• 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^[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.
• According to Sean O’Halpin's presentation unobtrusive metaprogramming, “every time you monkeypatch Object, a kitten dies”.

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.

[edit] References

[edit] See also

• Self-modifying code