views:

524

answers:

4

This is more general question then language-specific, altho I bumped into this problem while playing with python ncurses module. I needed to display locale characters and have them recognized as characters, so I just quickly monkey-patched few functions / methods from curses module.

This was what I call a fast and ugly solution, even it works. And the changes were relativly small, so I can hope I haven't messed up anything. My plan was to find another solution, but seeing it works and works well, you know how it is, I went forward to other problems I had to deal with, and I'm sure if there's no bug in this I won't ever make it better.

The more general question appeared to me though - obviously some languages allow us to monkey-patch large chunks of code inside classes. If this is the code I only use for myself, or the change is small, it's ok. What if some other developer takes my code though, he sees that I use some well-known module, so he can assume it works as it's used to. Then, this method suddenly behaves diffrent then it should.

So, very subjective, should we use monkey patching, and if yes, when and how? How should we document it?


edit: for @guerda:

Monkey-patching is the ability to dynamicly change the behavior of some piece of code at the execution time, without altering the code itself.

A small example in Python:

import os
def ld(name):
    print("The directory won't be listed here, it's a feature!")

os.listdir = ld

# now what happens if we call os.listdir("/home/")?
os.listdir("/home/")
+2  A: 

I would say don't.

Each monkey patch should be an exception and marked (for example with a //HACK comment) as such so they are easy to track back.

As we all know, it is all to easy to leave the ugly code in place because it works, so why spend any more time on it. So the ugly code will be there for a long time.

Gamecat
A: 

One word: oscommerce.

If you have never played with that before it is riddled with

// BOF: Fixed/added/removed bla bla bla
...
// EOF

Not to mention that the entire codebase has degraded due to the "put the functionality wherever you may be" mentality. Newer programming concepts such as OO (inheritance and composite classes come to mind) are designed to make these non-issues. Use them!

nlaq
A: 

I think the question can't be addressed with a single definitive yes-no/good-bad answer - the differences between languages and their implementations have to be considered.

In Python, one needs to consider whether a class can be monkey-patched at all (see this SO question for discussion), which relates to Python's slightly less-OO implementation. So I'd be cautious and inclined to expend some effort looking for alternatives before monkey-patching.

In Ruby, OTOH, which was built to be OO down into the interpreter, classes can be modified irrespective of whether they're implemented in C or Ruby. Even Object (pretty much the base class of everything) is open to modification. So monkey-patching is rather more enthusiastically adopted as a technique in that community.

Mike Woodhouse
+3  A: 

Don't!

Especially with free software, you have all the possibilities out there to get your changes into the main distribution. But if you have a weakly documented hack in your local copy you'll never be able to ship the product and upgrading to the next version of curses (security updates anyone) will be very high cost.

See this answer for a glimpse into what is possible on foreign code bases. The linked screencast is really worth a watch. Suddenly a dirty hack turns into a valuable contribution.

If you really cannot get the patch upstream for whatever reason, at least create a local (git) repo to track upstream and have your changes in a separate branch.

David Schmitt