Read the original article here.

---

The Forbidden Code: Underground Techniques

Chapter X: Monkey Patching - Rewriting Reality at Runtime

In the realm of programming, we are often taught principles of clean code, predictable behavior, and maintaining clear separation of concerns. We learn about modularity, stable APIs, and avoiding side effects. But what happens when you encounter a situation where the rules feel restrictive? Where a crucial piece of code, perhaps a third-party library or even a built-in function, doesn't behave exactly as you need it to, and altering its original source is impossible, impractical, or simply forbidden by the circumstances?

This is where "underground" techniques come into play. One such technique, powerful, controversial, and sometimes necessary, is monkey patching. It's the programming equivalent of changing the engine of a car while it's driving down the road. It allows you to reach into the live, running code of a program and alter its fundamental behavior on the fly.

What is Monkey Patching?

Let's start with a clear definition of this dynamic technique:

Definition: Monkey Patching

In computer programming, monkey patching is a technique used to dynamically update the behavior of a piece of code at run-time. It involves modifying or extending existing classes, modules, attributes, or functions (especially those from third-party libraries, frameworks, or even built-in language constructs) without altering the original source code files.

Think of it as overriding methods or replacing functions after the code has already been loaded into memory and is executing. Unlike standard inheritance or composition, which build on or around existing structures, monkey patching directly modifies the structure itself in the live environment.

This technique is primarily associated with dynamic programming languages such as Smalltalk, JavaScript, Objective-C, Ruby, Perl, Python, Groovy, Lisp, and Lua. These languages often have features like objects and classes being mutable at runtime, late binding, and the ability to treat classes as first-class objects, which facilitate this kind of dynamic modification.

Why "Forbidden Code"?

While not inherently malicious, monkey patching often deviates significantly from standard, easily traceable coding practices. It introduces changes that are not immediately visible by just reading the original source code, making programs harder to understand, debug, and maintain. It's a powerful tool for quick workarounds or deep customization, but it comes with substantial risks, which is why it's often avoided or discouraged in conventional, large-scale projects.

The Name: From Guerrilla to Monkey

The term "monkey patch" itself has an interesting, slightly murky origin that hints at its nature:

• Guerrilla Patch: The name seems to have evolved from an earlier term, "guerrilla patch." This term fittingly described changing code sneakily at runtime, often outside of standard procedures, much like guerrilla warfare operates outside conventional military structures. These patches could sometimes be incompatible with each other, leading to unpredictable conflicts.
• Gorilla/Monkey Homophones: The word "guerrilla," sounding similar to "gorilla," may have gradually transformed into "monkey." This shift might have been intended to make the technique sound slightly less intimidating or aggressive, perhaps emphasizing the idea of "monkeying about" or tinkering with the code.
• "Monkeying About": Another plausible etymology suggests the name comes from the phrase "monkeying about" with the code – essentially, messing with it in an informal or unauthorized way.

Interestingly, despite the name suggesting an unofficial or rogue activity, monkey patching is sometimes used in sanctioned ways, particularly for plugin systems or extensions in older software architectures. Early web browsers like Firefox and Internet Explorer, for instance, sometimes encouraged similar dynamic modifications for extensions before more structured API-based extension systems became standard. However, its most common association remains with unofficial, on-the-fly modifications.

Definitions Can Vary (Intent Matters)

The precise definition of "monkey patch" can sometimes depend on the specific programming community and the intent behind the dynamic modification.

• Ruby, Python, etc.: In many dynamic language communities, "monkey patch" specifically refers to dynamic modifications of a class or module at runtime that are motivated by the intent to patch existing third-party code as a workaround for a bug, a missing feature, or undesirable behavior.
• Other Intentions, Different Names: When similar dynamic class modifications are done with different intents, they might have different names. For example, in frameworks like Zope and Plone, security patches delivered by dynamically modifying classes at runtime are often called "hot fixes". While technically similar under the hood (dynamic code modification), the term "hot fix" implies an official, emergency patch provided by the vendor, rather than an independent workaround applied by a user.

This distinction highlights that the spirit of monkey patching often lies in modifying code you don't own or control, typically as a tactical fix.

The Power: Why Use This "Forbidden" Technique?

Given the risks, why would anyone resort to monkey patching? Its use cases often fall into scenarios where standard methods are insufficient or impossible:

1. Fixing Bugs or Adding Features to Third-Party Libraries: This is perhaps the most common (and often most justifiable) use case. You're using a library, you find a small bug, or you need a minor feature/behavior tweak. Getting the original author to fix it, waiting for a new release, or forking and maintaining your own version might be too time-consuming or impractical. Monkey patching lets you apply a fix or add behavior immediately to the version of the library you are currently using.

   • Example: A popular network library has a subtle bug in how it handles a specific error condition. You can monkey-patch the method that handles this error to correctly log the issue or retry the operation, without touching the library's source files.

2. Stubbing or Mocking for Testing: In software testing, you often need to isolate the code you are testing from its dependencies (like databases, external services, or complex components). Monkey patching is a powerful way to replace these dependencies with simplified "stubs" or "mocks" during the test run.

   • Example: You're testing a function that interacts with a remote API. Instead of making actual network calls during testing (which is slow and unreliable), you can monkey-patch the library function responsible for making the API call to simply return predefined test data.

3. Adapting Code to New Environments or Constraints: Sometimes, existing code needs to run in an environment with different constraints or requires interaction with systems it wasn't originally designed for. Monkey patching can adapt the code's behavior without rewriting large portions of it.

   • Example: An older piece of code uses a deprecated function. You can monkey-patch the deprecated function's name to point to the new function, making the old code work temporarily without modification.

4. Applying Patches to Running Systems (Hot Patching): In critical systems where downtime must be minimized, monkey patching allows applying urgent fixes directly to the live, in-memory state of the application without requiring a restart or full deployment. This is the essence of a "hot fix" when implemented via dynamic modification.

   • Example: A severe security vulnerability is found in a specific method of a running service. An emergency patch can be applied by replacing that method's implementation in the running process memory.

5. Extending Frameworks/Platforms: Some frameworks explicitly allow or implicitly rely on dynamic modification (similar to monkey patching) for their plugin or extension systems. While more structured than ad-hoc patching, it utilizes the underlying capability to change code behavior at runtime.

   • Example: Distributing a behavioral fix or a new feature for a web framework like Ruby on Rails as a plugin often involves modifying framework classes or modules after they've been loaded.

The Danger: Pitfalls of the Underground

The power of monkey patching is mirrored by its significant risks. These are the primary reasons why it's often labeled "forbidden" in standard development practices:

1. Upgrade Problems and Version Incompatibility: This is a major headache. A monkey patch often makes assumptions about the internal workings, method signatures, or attributes of the code it's patching. When the original library or framework is updated to a new version, these assumptions may no longer hold true. The patched code might break, cause unexpected errors, or behave subtly wrong in ways that are hard to diagnose. To mitigate this, monkey patches often need to include checks for the version of the code being patched, making them more complex.

2. Patch Collisions and Order Dependency: If multiple parts of a system or multiple third-party libraries you use all decide to monkey-patch the same method or attribute, chaos can ensue. The patch that is applied last will typically "win," overwriting any previous patches. This leads to unpredictable behavior depending on the load order of modules, which can be notoriously difficult to control and debug. Specific patterns (like Ruby's alias_method_chain or manually wrapping methods) can be used to chain patches, but this adds complexity and requires coordination.

3. Debugging Nightmares and Code Obscurity: This is perhaps the most insidious pitfall. When code is monkey-patched, the observed behavior in a running program no longer matches the original source code on disk. Developers looking at the source might assume the code does one thing, while the running program does something completely different because of a hidden patch. Standard debuggers may struggle to show the active, patched code. This discrepancy makes understanding, debugging, and troubleshooting significantly harder for anyone unaware of the patch's existence. Some systems, like the Linux kernel mentioned in the source, actively try to detect third-party modifications to kernel structures precisely because they can introduce hard-to-debug issues that core developers cannot fix.

4. Potential for Malicious Use: The ability to arbitrarily alter the behavior of code at runtime can be exploited for malicious purposes. An attacker or a malicious plugin could modify the program's behavior to bypass security checks, log sensitive data, inject harmful code, or even sabotage other parts of the program or other patches.

   • Example: The incident involving the Firefox Adblock Plus and NoScript extensions, where one extension attempted to monkey-patch the other to force ads through and prevent users from disabling them, is a stark example of how this technique can be used in a hostile manner to subvert user intent and engage in a digital conflict.

A Simple Example (Python)

Let's look at the classic Python example provided, which demonstrates monkey patching by altering a fundamental mathematical constant:

import math

# Print the original value of Pi from the standard library
print(f"Original math.pi: {math.pi}")

# --- THE FORBIDDEN ACT ---
# We are going to monkey-patch the value of Pi
# Imagine we believe in the (erroneous) Indiana Pi Bill which proposed Pi = 3.2
print("\nPerforming forbidden modification: Monkey-patching math.pi to 3.2...")

# In Python, module attributes are mutable at runtime
# We can simply reassign the 'pi' attribute of the 'math' module object
math.pi = 3.2

print(f"Monkey-patched math.pi: {math.pi}")

# --- CONSEQUENCES ---
# Any code that uses math.pi AFTER this point in this running program instance
# will use the new, incorrect value (3.2) instead of the standard value (3.14159...)
print(f"\nUsing the patched value in a calculation: Circumference of circle with radius 1 (2 * pi * r): {2 * math.pi * 1}")

# This change is only for THIS running process.
# It does NOT change the math.py source file on disk.

Explanation:

1. We import the standard math module.
2. We print the original value of math.pi.
3. We then reassign the pi attribute within the loaded math module object in memory. In Python, modules are objects, and their contents (functions, variables, etc.) are accessible as attributes, which can often be modified dynamically.
4. After this line, any code that accesses math.pi in this running program will get the value 3.2.
5. Crucially, this modification only affects the current process instance. The math.py file on your file system remains unchanged.

This simple example, while trivial, illustrates the core principle: you can reach into an imported module or object and change its properties or methods at runtime.

Related Underground Concepts

Monkey patching is related to, or can be used to implement, other techniques often found in advanced or unconventional programming scenarios:

• Dynamic Loading: Loading code (like shared libraries or modules) at runtime is a prerequisite for monkey patching, as you need the target code in memory to modify it dynamically.
• Aspect-Oriented Programming (AOP): AOP aims to modularize "cross-cutting concerns" (like logging, security, transaction management) by adding behavior ("advice") at specific points ("join points") in a program's execution (like before/after/around method calls). Monkey patching can be used as a low-level way to implement AOP-like behavior manually by wrapping or replacing methods. However, AOP frameworks provide a more structured and less error-prone way to achieve this.
• Self-Modifying Code: Monkey patching is a form of self-modifying code, where the program alters its own instructions or structure while running. While traditional self-modifying code often dealt with machine code, monkey patching typically operates at the level of language objects, classes, and methods.
• Polyfill: While not strictly monkey patching, a polyfill attempts to provide a standard piece of functionality that is missing in an older environment (like a browser). This is often done by checking if a method/property exists on a built-in object (like Array.prototype) and adding it if it doesn't. If the implementation replaces an existing, non-compliant method, it can blur the lines and resemble monkey patching, though the intent is standardization rather than patching a bug.

When is it (Relatively) Okay?

Despite the dangers, monkey patching isn't always pure evil. It can be considered in specific, limited circumstances:

• Urgent Hot Fixes: For critical, production systems where downtime is unacceptable and an immediate fix is needed and provided by a trusted source (like the library vendor themselves in a "hot fix").
• Testing: As demonstrated, it's a standard and accepted technique for creating test doubles (stubs, mocks) to isolate units of code for testing.
• Temporary Workarounds: Applying a very short-term fix for a known bug in a dependency when waiting for an official release is impossible, provided the patch is heavily documented, isolated, and planned for removal as soon as the official fix is available.
• Highly Controlled Extension Points: When a framework or library explicitly uses and documents a dynamic modification mechanism as its intended extension point (though this often moves away from the "guerrilla" spirit).

Even in these cases, the risks remain.

Conclusion: A Tool of Last Resort or Specific Design

Monkey patching is a potent technique that allows developers to break the usual rules of program structure and execution by dynamically altering code at runtime. It bypasses the original source, offering immediate power to fix bugs, extend behavior, or facilitate testing in ways that static code cannot.

However, its power comes at a significant cost. It creates hidden dependencies, makes debugging a nightmare, is fragile in the face of updates, and opens doors for patch conflicts or even malicious manipulation.

In the context of "The Forbidden Code," monkey patching is a prime example of a technique that gives you control but demands extreme caution, deep understanding of the underlying system, and a willingness to accept increased complexity and fragility. It's not a tool for the faint of heart or for everyday coding. It's a specialized technique, often a tool of last resort, best used sparingly, documented meticulously, and understood by all involved. Using it without acknowledging its dangers is inviting chaos into your codebase.