Comments on: Monkey Patching Core Functionality == BAD, BAD, BAD

By: Chris McGrath

Chris McGrath — Wed, 30 Nov -0001 00:00:00 +0000

I was bitten by this too when upgrading haml, I pity the fools without tests!

By: Stephan Leclercq

Stephan Leclercq — Wed, 30 Nov -0001 00:00:00 +0000

Not even unit tests will help you in that case. A perfectly well written module will work in one application (including in your test fixture) and break in another !

I pity the fools using any language that allows such stupid constructs.

By: michaelw

michaelw — Wed, 30 Nov -0001 00:00:00 +0000

@Stephan:
How is that different from subclassing a Java class, then overwriting a method (say, equals), with a version that violates its contract? Pretty hard to detect automatically, and it happens all the time in the wild.

I am far from defending monkey patching, but I’d rather have a language which is unsafe in places than one which is safe to the point that I can’t get anything done.

As for the particular problem instance, perhaps the Ruby runtime could warn when it overrides a method, and (unless permitted by some configuration option) bail out if it detects overriding of core functionality.

By: Craig

Craig — Wed, 30 Nov -0001 00:00:00 +0000

@michaelw: Monkey patching is entirely different to subclassing. For a start, subclasses are part of the static type system, and therefore are known before compilation and are guaranteed not to change afterward. To change a method by subclassing, you must create a new type that inherits from the original, following the language’s rules on inheritance (protected, private, etc) and that type exists in your own code. It only affects objects of that type that you specifically create, whereas monkey patching affects EVERY instance of the base type.

In summary, inheritance is a controlled, static way of creating new types that behave similarly, but differently, to other types. Monkey patching is a way of hacking behaviour into classes, outside of any sort of type control system. It can create hard to find bugs like this one because you never know, at runtime, whether the method you are calling is quite the one you expect.

By: she/farun@hotmail.com

she/farun@hotmail.com — Wed, 30 Nov -0001 00:00:00 +0000

First, it is nice that you allow blog comments. I applaude everyone that allows the visitors to voice their opinion on something. Many blogs dont want that.

Second, I agree that the described behaviour CAN be bad. But it is like the swiss knife – you dont need everything, but if you need it, it is there. Same with Ruby.
The thing is, while I do extend core classes of Ruby happily, I am somewhat wary to see this being done in other projects – I think I am agreeing with you on that.

The documentation should point this out somehow, so that a user can be aware of this.

However, and this must be said, the term “monkey patching” is derogative and incorrect. I refuse to see such a name used for the described behaviour, and whenever I see proponents of this terms using it, I go and flame them. But of course not in your blog, since you allow comments.

I will happily flame them on mailing lists whenever they refer to changing behaviour of core objects as “monkey patching”. (It has happened at least twice before on the Ruby mailing list by two different people.)

By: Michael Campbell

Michael Campbell — Wed, 30 Nov -0001 00:00:00 +0000

I’m still confused on this particular example; why is comparing a sorted array of nils to another sorted array of nils returning true, bad? Did I misread?

By: Avdi

Avdi — Wed, 30 Nov -0001 00:00:00 +0000

Nice example of one of the more subtle monkey patching gotchas.

By: Robert 'Groby' Blum

Robert 'Groby' Blum — Wed, 30 Nov -0001 00:00:00 +0000

It can create hard to find bugs like this one because you never know, at runtime, whether the method you are calling is quite the one you expect.

You mean, sort of like C++ with virtual overrides, slicing, operator overloads, implicit casts and constructors? :->

Corollary to this is that you need a executable spec for all classes you rely on – monkey patching is going to happen, whether it’s useful or not. As far as I know, there are a couple of efforts underway to cover Ruby’s base behavior with RSpec.

By: Kurt Schrader

Kurt Schrader — Wed, 30 Nov -0001 00:00:00 +0000

Michael: The spec should have been testing that the arrays had two equal sorted group of values in them, but because the test setup was incorrect, the methods were returning arrays of nils.

Normally, [nil, nil] would throw an exception when you try to sort it, but it wasn’t doing that any longe because of the patch.

I should have done a better job explaining that.

By: Stephan Leclercq

Stephan Leclercq — Wed, 30 Nov -0001 00:00:00 +0000

@Michaelw : it is different because if I subclass String and replace a functionality, only modules that use my new String class (ie my own modules) will be affected by my changes. Otherwise, even the test framework itself may be affected and hit false positives or worse, false negatives.

>> bail out if it detects overriding of core functionality

What should be considered core functionality? You will not be able to find a suitable agreement for that. You will always find people complaining it to be either too restrictive or too loose (including me: -)