Gilad Bracha on extending system code:

One way of achieving this would be to actually go and add the necessary methods to the class Symbol, so that symbols could behave like parsers. I know otherwise intelligent people who are prepared to argue for this approach. As I said, Smalltalkers would call these additions extension methods, but I find the more informal term monkey patching conveys a better intuition.

Typically, one wants to deliver a set of such methods as a unit, to be installed when a certain class or library gets loaded. So these changes are often provided as a patch that is applied dynamically. Not a problem in Smalltalk or Ruby or Python (though I gathered from the Pythoners in Krakow that they, to their credit, frown on the practice).

Apparently, there is a need to explain why monkey patching is a really bad idea. For starters, the methods in one monkey’s patch might conflict with those in some other monkey’s patch. In our example, the sequencing operator for parsers conflicts with that for symbols.

Hmm. First, version control systems exist partly for that reason - to let developers look at exactly those kinds of conflicts. Second, would Bracha rather see developers in Smalltalk (et. al.) use the same kind of "support class" nonsense that Java developers have been locked into for years?

Sure, you can get in trouble with conflicting extensions - in BottomFeeder, I ran into exactly that problem when I started using Antony Blakey's improved Look and Feel policy. Here's the thing though: I spoke to Antony, and, after we talked a bit, we dealt with the problem. So let me see: my solution involved more and better communication between developers. Bracha's involves "just say no".

Call me crazy, but I think my approach seems far more practical in the real world. At the end of the day, his approach comes from the school of thought I like to call "the library developer is god".

Hat tip Patrick Logan

Technorati Tags: monkey patching, smalltalk