Yep, “MonkeyPatching” is the hot new word of the day. All the cool bloggers are dropping it left and right. I’d never heard the term til a few weeks ago. Now it seems I can’t go a day without reading it in at least a couple blog posts.
But until this morning, I didn’t really know what it meant. I had my own invented meaning – something vague about writing some hack to fix someone else’s broken code. “Dude, I totally had to monkey patch that data grid to get the cell renderer to scale correctly.”
In fact, it has a very specific, technical meaning. From WikiPedia:
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, and Python) without altering the original source code.
This all came about after reading this post at Coding Horror.
My initial thoughts on reading this was that the ActionScript community is running an almost directly opposite timeline from these guys. Back in ActionScript 1.0 days, MonkeyPatching was the epitome of hardcore programming. Remember prototype? 🙂 Remember layer51.com? (It’s still there.) Layer51 is a massive repository of AS1 MonkeyPatches. You want to know if two different arrays are equal? Grab the Array.equals() method (by senocular):
[as]Array.prototype.equals = function(a){
if (this == a) return true;
var i = this.length;
if (i != a.length) return false;
while(i–) if (this[i] != a[i]) return false;
return true;
}
/**** EXAMPLE ****\
a = [1,2,3,4];
b = [1,2,3,4];
c = [1,2,3,5];
d = a;
trace(a.equals(b)); // true
trace(a.equals(c)); // false[/as]
Layer51 sports 370 MonkeyPatches to MovieClip. The thing I didn’t like about using such “prototypes” (as they were often misnamed) was that they get added to every instance of the class you are patching. For example, if you use the double click patch, every single movie clip in your movie now has double click functionality. And since there were no dynamic shapes or sprites back then, pretty much everything was built on movie clips. Chances are you only had one, or maybe a few movie clips you actually needed to have this functionality. So it falls into the “Excessively wide in scope” category as mentioned in the Coding Horror link above.
These days in the ActionScript community, any mention of adding functionality via prototype is usually mentioned as an inside joke. I know prototype still exists in AS3, but I honestly don’t know if it would still be possible to use it in the way we used to, because nobody even seriously talks about doing so. We seem to be very proud of the fact that ActionScript has gotten less and less dynamic as time has gone by. Heck, in AS3, private properties are really private even. Strict typing is enforced at run time. The MovieClip class is still marked as dynamic, for old time’s sake, but most other classes, including the more commonly used Sprite, are not.
Anyway, I just thought it was funny that while developers in these other languages, including c#, are discovering the joys of MonkeyPatching, we are leaving it behind more and more. Are we way ahead of the curve or way behind it?
That really depends on whether or not we are going round in circles.
Its interesting to see the directions of these languages as they move forward. There’s certainly a sweet spot for web programming (“scripting”?) in terms of flexibility and scalability. They don’t often compliment each other and supporting one more can usually mean giving up some of the other.
I’m not too familiar with C# but I’d be curious to see how it handles conflicts with duplicate extension methods.
Nice post. Memories… Makes me feel like some crazy C programmer or something thinking back to the old days. I love your comment, “for old times sake.” Awesome… I’d say AS3 coders are ahead of the curve considering we could do the old school proto style coding if we really wanted to. But I think we’ve been there and hopefully learned a few reasons why imposing a few rules is a good thing. AS1 makes me cringe anymore….
the good old days 🙂
You can still replace most of those “prototyping” solutions with utility classes… i.e. array1.equals( array2 ) can be changed to ArrayUtil.equals( array1, array2 ) (with only a minor loss in readability) which solves the problem of adding extra functionality to every Array in your app.
Ryan, yes, of course. That’s the whole point. There are much better solutions than monkeypatching in most cases, such as a utility class or creating a new class that extends Array or uses Array via composition and adds new features. I’d love to hear some argument in favor of monkeypatching. Does it all come down to having to write less code? Is there some other benefit?
“I’d love to hear some argument in favor of monkeypatching.”
It;s feasible that all your components or all lists etc in Flex to have something added to them. It’s much easier to monkeypatch UIComponent/ListBase, than create your own, the re-write every class extending that.
We currently have a project were we are monkeypatching DownloadProgressBar as we wanted to add some default look and functionality to the default DownloadProgressBar in a library project for a client, and it wasn’t possible to specify a default progressbar with AS, only MXML.
http://bugs.adobe.com/jira/browse/SDK-14911
After reading this, I think I may change the title on my business card to “Monkey Patcher”.
My first encounter with monkey patch was by Matt Chotin (http://weblogs.macromedia.com/mchotin/archives/2007/11/have_you_monkey.cfm) and I had the same vague idea as you. Thank you for shedding more light on this!
As a onetime hardcore C++ developer, I sometimes miss operator overloading, i.e. being able to write a1 == a2 instead of FooUtil.equals(a1,a2). Then you really gain in readability especially in multiple conditions…
Tink, I see what you are talking about. I guess it comes down to:
1. Is there a “proper” way to do what you are doing? (e.g. Extend the scroll bar class and extend every class that uses a scroll bar.)
2. Do you have a good reason for monkeypatching rather than doing it the proper way? (e.g. re-writing every class that uses a scroll bar is ridiculous.)
3. Have you considered the potential pitfalls of what you are doing and safeguarded against them as necessary? (e.g. is someone else going to try to use code that depends on your patch, but not know about the patch?)
From what I’m seeing, the term “monkey-patching” has gained popularity mostly in the Flex community, where it is used to describe altering the Flex framework at the source code level to overcome some shortcoming or bug. We actually are replacing the source code bits with our own – getting the compiler to take our modified source over what’s in the SDK. Based on the definition, maybe we’re using the term incorrectly since we’re not using extension, and we’re modifying source code.
In Actionscript 2 many developers promoted: ‘Usally it’s good practise to use strong typing. But If you know what you do and need loose typing, it can be usefull.’ Nowadays loose typing is the worst thing you can do (if you still could use it). 😉
Personally I’ve never used prototypes but I like dynamic classes, if needed, and feel happy about that the movieclip class is at least still dynamic (‘for old time’s sake’).
I am not sure about it, but I got the feeling that loosing dynamic ‘featres’ means need to make more use of inheritance, which isn’t always the best way.
It’s slightly amusing (but mostly annoying) that the junior-level developers of today think that by inventing a new word such as “monkeypatching” and applying it to poor coding practices that it’s something cool and clever. No matter which way you implement clever little “patches” they’re still unmaintainable in the long run and just lead to another variation of spaghetti code. Personally, I’ve had to fix far too much of that sort of garbage code and all because someone previously thought they were being soooo clever when, in fact, they were just being a lazy developer leaving needless liabilities behind for both the company and their peers. If you’re going to pretend to be an object-oriented developer then at least try to reduce the scope of your modifications. Whatever happened to inheritance???