What does 'Monkey Patching' exactly Mean in Ruby?

[Yaser_S]

According to Wikipedia, a monkey patch1 is:

a way to extend or modify the runtime code of dynamic languages […]
without altering the original source code.

The following statement from the same entry confused me:

In Ruby, the term monkey patch was misunderstood to mean any dynamic
modification to a class and is often used as a synonym for dynamically
modifying any class at runtime.

I would like to know the exact meaning of monkey patching in Ruby. To be
more specific, I would like to know the answers to the following
questions:

1- What does “runtime code” refer to in Ruby?

2- Are “monkey patching” and “open classes” different terms for the same
thing?

3- Is the following considered as monkey patching, or is it something
else?

class String
def foo
“bar”
end
end

Regards,
Yaser S.

P.S. I originally posted this question on stackoverflow2. There are
some
good
answers over there, but I’m still kinda confused. I hope that someone in
the
Ruby
community can clarify this issue for me.

[Yaser_S]

On Sat, Dec 27, 2008 at 4:17 PM, Yaser S. [email protected]
wrote:

I would like to know the exact meaning of monkey patching in Ruby. To be
more specific, I would like to know the answers to the following questions:

1- What does “runtime code” refer to in Ruby?

2- Are “monkey patching” and “open classes” different terms for the same
thing?
I guess this is the critical point why the Wikipedia article says
“misunderstood”
as in Ruby even core classes are open MP just does not really mean
anything else for core classes
and your own classes or any other imported classes.

3- Is the following considered as monkey patching, or is it something else?

class String
def foo
“bar”
end
end

I would consider it MP

Regards,
Yaser S.

P.S. I originally posted this question on stackoverflow2. There are some
good
answers over there, but I’m still kinda confused. I hope that someone in the
Ruby
community can clarify this issue for me.
Hopefully
Cheers
Robert

–
Il computer non è una macchina intelligente che aiuta le persone
stupide, anzi, è una macchina stupida che funziona solo nelle mani
delle persone intelligenti.
Computers are not smart to help stupid people, rather they are stupid
and will work only if taken care of by smart people.

Umberto Eco

[Yaser_S]

Hi –

On Sun, 28 Dec 2008, Yaser S. wrote:

I would like to know the exact meaning of monkey patching in Ruby.

There’s no exact meaning. Some people use it to mean re-opening core
classes; some people use it to mean re-opening core classes in an
incompetent, unsafe manner; some people use it as a way of indicating
that any time you re-open a core class, you shouldn’t (which is a
well-intentioned but reductive position); some people use it to mean
re-opening non-core classes; and so on.

It’s basically a negative, uninformative, rather silly term that has
nothing going for it. I personally don’t use it. I’m a minority of
about one, though

David

[Yaser_S]

Yaser S. wrote:

1- What does “runtime code” refer to in Ruby?

In WikiPedia’s world, all applications have code that executes for the
end-user,
and support code - such as compilers, test files, code generators, etc.
Runtime
code is the former.

3- Is the following considered as monkey patching, or is it something else?

class String
def foo
“bar”
end
end

No, that is simply extending the class with a new method. Ruby classes
are
always open for extension, and the article you cited implied the
misunderstanding was that is monkey patching. It is not.

This is monkey patching:

class String
def length
42
end
end

The method .length already existed, but we had our way with it. And this
example
shows why MP is kind’a dangerous. Ruby has no mechanism to allow only
our own
modules to see our patches. My example gives all library code a bogus
string
length, and our runtime code would not last very long…

Unfortunately for those who fear Monkey Patching, many Ruby libraries
rely on
it. They are released rough-and-ready, before any serious effort to
detect where
to install “hooks” (look up “Abstract Template Design Pattern”). So to
get
anything done in a big Ruby application, your monkeys will be frequently
climbing up your inheritance trees and patching the code they find
there!

WP is full of biases and points-of-view; use it carefully!!

[Yaser_S]

2008/12/27 David A. Black [email protected]:

It’s basically a negative, uninformative, rather silly term that has
nothing going for it. I personally don’t use it. I’m a minority of
about one, though

I’d say “about two”.

robert

[Yaser_S]

On 27.12.2008 16:17, Yaser S. wrote:

modification to a class and is often used as a synonym for dynamically
modifying any class at runtime.

I would like to know the exact meaning of monkey patching in Ruby. To be
more specific, I would like to know the answers to the following questions:

I am by no means authoritative for the subject.

1- What does “runtime code” refer to in Ruby?

It refers to the code that is shipped with the interpreter or other
runtime system (e.g. String, Hash, Array, Fixnum and the like). Usually
a lot other code depends on this and a monkey patch has a certain
potential to wreck havoc on the whole application.

2- Are “monkey patching” and “open classes” different terms for the same
thing?

Yes, of course. “Open classes” is a general concept, while “monkey
patching” is a methodology (at least something procedural). You can use
“open classes” to do “monkey patching” - but there are other tools as
well that you can use to do it (e.g. you could try to overwrite code in
memory or in C change the pointer of a basic function like strlen).

3- Is the following considered as monkey patching, or is it something else?

class String
def foo
“bar”
end
end

I would not call this “monkey patching” because although you modify a
core class you do not modify a core functionality. Most of the time I
have seen “monkey patching” denote a change to core functionality with
potentially far reaching consequences, e.g. this would rather be a
monkey patch

class Object
def to_s
“boom!”
end
end

because it has potential to make certain things work but also break a
lot of code.

Cheers

robert

[Yaser_S]

On Sat, Dec 27, 2008 at 8:49 PM, Robert K.
[email protected] wrote:

2008/12/27 David A. Black [email protected]:

It’s basically a negative, uninformative, rather silly term that has
nothing going for it. I personally don’t use it. I’m a minority of
about one, though

I’d say “about two”.

Four at the least

m.

[Yaser_S]

David A. Black wrote:

It’s basically a negative, uninformative, rather silly term that has
nothing going for it. I personally don’t use it. I’m a minority of
about one, though

Minority of at least two.

[Yaser_S]

Martin DeMello wrote:

On Sat, Dec 27, 2008 at 8:49 PM, Robert K.
[email protected] wrote:

2008/12/27 David A. Black [email protected]:

It’s basically a negative, uninformative, rather silly term that has
nothing going for it. I personally don’t use it. I’m a minority of
about one, though
I’d say “about two”.

Four at the least

Cool! We can be a gang!

–
James B.

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

[Yaser_S]

Hi –

On Sun, 28 Dec 2008, marc wrote:

The following statement from the same entry confused me:
that any time you re-open a core class, you shouldn’t (which is a
well-intentioned but reductive position); some people use it to mean
re-opening non-core classes; and so on.

My brain is fuddled today recovering from flu, but what do you mean by
“reopening”?

Like this:

class Array
def my_new_method
end
end

where I’m reopening the core Array class and adding and/or overriding
methods in it.

David

[Yaser_S]

David A. Black said…

well-intentioned but reductive position); some people use it to mean
re-opening non-core classes; and so on.

My brain is fuddled today recovering from flu, but what do you mean by
“reopening”?

[Yaser_S]

Robert K. wrote:

class Object
def to_s
“boom!”
end
end

I CAN HAZ LULZ!1!!11!

Dave

[Yaser_S]

It’s basically a negative, uninformative, rather silly term that has
nothing going for it. I personally don’t use it. I’m a minority of
about one, though

I’d say “about two”.

Four at the least

m.

Based on the evidence before you, Martin, you can only conclude “Three
at the least”. James didn’t declare his hand.

Cheers,
Gavin

[Yaser_S]

David A. Black said…

Like this:

class Array
def my_new_method
end
end

where I’m reopening the core Array class and adding and/or overriding
methods in it.

Okay, so reopening is extending or overriding (a method of) a core
class. Good to know the lingo.

And I concur with your earlier assertion regarding the MP term:

It’s basically a negative, uninformative, rather silly term that has
nothing going for it.

[Yaser_S]

Thank you for your answers, everyone. They were really informative.

On Sat, Dec 27, 2008 at 6:56 PM, David A. Black [email protected]
wrote:

There’s no exact meaning.

I couldn’t agree more. It almost seems like every one has his own
special
understanding of the term. But I guess that this isn’t always a bad
thing.
After all, in a community of more than one person, there will always be
a
thing that the community can’t agree upon.

On Sun, Dec 28, 2008 at 2:16 AM, James B. [email protected]
wrote:

Cool! We can be a gang!

Count me in! - but I still think that the term ‘monkey patching’ is
cooler/funkier than ‘open classes’

Regards,
Yaser

[Yaser_S]

Phlip wrote:

Yaser S. wrote:

3- Is the following considered as monkey patching, or is it something else?

class String
def foo
“bar”
end
end

No, that is simply extending the class with a new method.

Ah, but that’s the interesting part: how do you know that somebody
else didn’t already add a String#foo method? In that case, it would
be monkey patching. Even worse: which of the two methods would be
considered monkey patching and which one wouldn’t, would depend
entirely on the load order of those two snippets of code.

That’s why I don’t think distinguishing between adding and changing
methods makes sense: either both are monkey patching or neither are.

jwm

[Yaser_S]

Ah, but that’s the interesting part: how do you know that somebody
else didn’t already add a String#foo method?

That’s why it’s not “elegantly patching with surgical precision”.

You weren’t the monkey - for publishing such a silly method. They
were!

(Stating this as a guideline - if it’s a vanilla method name like
‘.length’,
it’s a monkey patch, and if it’s application-specific you should give it
a weird
name, like ‘.__my_boss_my_app_length’.)

[Yaser_S]

Hi –

On Fri, 2 Jan 2009, Jörg W Mittag wrote:

No, that is simply extending the class with a new method.

Ah, but that’s the interesting part: how do you know that somebody
else didn’t already add a String#foo method? In that case, it would
be monkey patching. Even worse: which of the two methods would be
considered monkey patching and which one wouldn’t, would depend
entirely on the load order of those two snippets of code.

That’s why I don’t think distinguishing between adding and changing
methods makes sense: either both are monkey patching or neither are.

This was true, and quite deeply examined, well before the term “monkey
patching” came along to cloud the issue

Adding a new method involves a kind of Prisoners’ Dilemma, situation,
where if either of us is the only one to add that particular method,
we “win”, but if we both do it, we lose. Changing methods, however,
can be done in a relatively low-impact way, if you chain them rather
than really changing them.

I’ll put in a plug for what I believe is by far the safest way to
extend core functionality, namely #extend. A classic case is the
desire to have #gsub! not return nil when the string doesn’t change.

module MyGsubBang
def gsub!(*args, &block)
super(*args, &block) || self
end
end

str = “abc”.extend(MyGsubBang)

Among other advantages, this way of doing it forces you to think
carefully about the specific objects, and not throw too large a
blanket over what is actually a tiny problem (having one or two
objects that you want to behave different from the norm).

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

http://www.wishsight.com => Independent, social wishlist management!

[Yaser_S]

On Fri, Jan 2, 2009 at 1:42 PM, David A. Black [email protected]
wrote:

str = “abc”.extend(MyGsubBang)
This indeed is a very sensible and elegant way to do things.

The true werewolf of dynamic extension (I am happy with MP but there
seems to be a consensus against that term…) however is this case

first I am using what I have just learned from David

module VersionIndependentInstanceMethods
def instance_methos *args, &blk
super.map{ |mn| mn.to_sym }
end
end
Class.include Version…

class WhatEverOrMaybeEvenACoreClass
if instance_methods.include? :xxx then
raise IDoNotKnowWhatToDoError, “No I really don’t”
else
def xxx …
end
end
end

Any insights on IDoNotKnowWhatToDoError?

Cheers
Robert

[Yaser_S]

module MyGsubBang
def gsub!(*args, &block)
super(*args, &block) || self
end
end

str = “abc”.extend(MyGsubBang)

str += “1”

This would return a normal string. You’d then have to extend those
strings again and again. Please correct me if I’m wrong but IMHO this
approach brings little advantage over defining a subclass of String:

class MyString < String
…
end

str = MyString.new(“abc”)

This creates a copy of “abc” in this particular case but provides IMHO
more flexibility. With some extra work you could catch those cases
where the function returns a new string, eg something in the line of:

class MyString < BasicObject

YOUR METHODS HERE

def method_missing(...)
    ...
end

end

The extra indirection has its drawbacks of course.

The conclusion IMHO is twofold: (1) “monkey patching” is ok if you’re
the only user of your code (in which case it is okay to use a silly
name for that practice) or if the extensions are part of a well
documented supplementary library/framework where those extended
methods become some sort of standard. (2) Beware of people who are
proud of their monkey tactics.