# What does 'Monkey Patching' exactly Mean in Ruby? **URL:** \ **Category:** ruby-talk\ **Created:** [27 December 2008 15:17 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895 "2008-12-27T15:17:03Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Yaser\_Sulaiman](https://avatars.discourse-cdn.com/v4/letter/y/7c8e57/32.png) [@Yaser\_Sulaiman](https://rubytalk.org/u/Yaser_Sulaiman)\ **Post date:** [27 December 2008 15:17 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/1 "2008-12-27T15:17:03Z")
According to Wikipedia, a monkey patch[1] 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 Sulaiman P.S. I originally posted this question on stackoverflow[2]. 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. [1]: [Monkey patch - Wikipedia](http://en.wikipedia.org/wiki/Monkey_patch) [2]: [terminology - What does 'Monkey Patching' exactly Mean in Ruby? - Stack Overflow](http://stackoverflow.com/questions/394144/what-does-monkey-patching-exactly-mean-in-ruby) ---
**Author:** ![Forum](https://avatars.discourse-cdn.com/v4/letter/f/43a26b/32.png) [@Forum](https://rubytalk.org/u/Forum)\ **Post date:** [27 December 2008 15:49 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/2 "2008-12-27T15:49:11Z")
> According to Wikipedia, a monkey patch[1] 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? 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 Sulaiman > > P.S. I originally posted this question on stackoverflow[2]. 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 > **路路路** > > On Sat, Dec 27, 2008 at 4:17 PM, Yaser Sulaiman \ wrote: > > > [1]: [Monkey patch - Wikipedia](http://en.wikipedia.org/wiki/Monkey_patch) > > [2]: > > [terminology - What does 'Monkey Patching' exactly Mean in Ruby? - Stack Overflow](http://stackoverflow.com/questions/394144/what-does-monkey-patching-exactly-mean-in-ruby) > > -- > 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 ---
**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\ **Post date:** [27 December 2008 15:56 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/3 "2008-12-27T15:56:57Z")
Hi -- > According to Wikipedia, a monkey patch[1] 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. 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 > **路路路** > > On Sun, 28 Dec 2008, Yaser Sulaiman wrote: > > -- > David A. Black / Ruby Power and Light, LLC > Ruby/Rails consulting & training: [http://www.rubypal.com](http://www.rubypal.com) > Coming in 2009: The Well-Grounded Rubyist ([http://manning.com/black2\](http://manning.com/black2%5C)) ---
**Author:** ![Phlip1](https://avatars.discourse-cdn.com/v4/letter/p/df788c/32.png) [@Phlip1](https://rubytalk.org/u/Phlip1)\ **Post date:** [27 December 2008 15:59 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/4 "2008-12-27T15:59:49Z")
Yaser Sulaiman 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! > [1]: [Monkey patch - Wikipedia](http://en.wikipedia.org/wiki/Monkey_patch) WP is full of biases and points-of-view; use it carefully!! > **路路路** > > -- >    Phlip ---
**Author:** ![Robert\_K1](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/robert_k1/32/1830_2.png) [@Robert\_K1](https://rubytalk.org/u/Robert_K1)\ **Post date:** [27 December 2008 16:04 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/5 "2008-12-27T16:04:49Z")
> [Note: parts of this message were removed to make it a legal post.] > > According to Wikipedia, a monkey patch[1] 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: \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 > **路路路** > > On 27.12.2008 16:17, Yaser Sulaiman wrote: > > -- > remember.guy do |as, often| as.you\_can - without end ---
**Author:** ![Robert\_K1](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/robert_k1/32/1830_2.png) [@Robert\_K1](https://rubytalk.org/u/Robert_K1)\ **Post date:** [27 December 2008 16:49 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/6 "2008-12-27T16:49:10Z")
I'd say "about two". 馃檪 robert > **路路路** > > 2008/12/27 David A. Black \: > > > 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 馃檪 > > -- > remember.guy do |as, often| as.you\_can - without end ---
**Author:** ![James\_Britt3](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@James\_Britt3](https://rubytalk.org/u/James_Britt3)\ **Post date:** [27 December 2008 18:18 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/7 "2008-12-27T18:18:15Z")
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. > **路路路** > > -- > James Britt ---
**Author:** ![marc1](https://avatars.discourse-cdn.com/v4/letter/m/49beb7/32.png) [@marc1](https://rubytalk.org/u/marc1)\ **Post date:** [28 December 2008 11:16 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/8 "2008-12-28T11:16:40Z")
David A. Black said... > Hi -- > > \> According to Wikipedia, a monkey patch[1] 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. > > 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. My brain is fuddled today recovering from flu, but what do you mean by "reopening"? > **路路路** > > > On Sun, 28 Dec 2008, Yaser Sulaiman wrote: > > -- > Cheers, > Marc ---
**Author:** ![Dave\_Bass](https://avatars.discourse-cdn.com/v4/letter/d/f6c823/32.png) [@Dave\_Bass](https://rubytalk.org/u/Dave_Bass)\ **Post date:** [28 December 2008 12:09 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/9 "2008-12-28T12:09:33Z")
Robert Klemme wrote: > class Object >    def to\_s >      "boom!" >    end > end I CAN HAZ LULZ!1!!11! Dave > **路路路** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Jorg\_W\_Mittag2](https://avatars.discourse-cdn.com/v4/letter/j/e79b87/32.png) [@Jorg\_W\_Mittag2](https://rubytalk.org/u/Jorg_W_Mittag2)\ **Post date:** [2 January 2009 08:11 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/10 "2009-01-02T08:11:26Z")
Phlip wrote: > Yaser Sulaiman 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 ---
**Author:** ![Martin\_DeMello](https://avatars.discourse-cdn.com/v4/letter/m/f17d59/32.png) [@Martin\_DeMello](https://rubytalk.org/u/Martin_DeMello)\ **Post date:** [27 December 2008 21:43 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/11 "2008-12-27T21:43:02Z")
Four at the least 馃檪 m. > **路路路** > > On Sat, Dec 27, 2008 at 8:49 PM, Robert Klemme \ wrote: > > > 2008/12/27 David A. Black \: > > > > > 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". 馃檪 ---
**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\ **Post date:** [28 December 2008 11:18 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/12 "2008-12-28T11:18:30Z")
Hi -- > David A. Black said... > > > Hi -- > > > > > According to Wikipedia, a monkey patch[1] 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. > > > > 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. > > 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 > **路路路** > > On Sun, 28 Dec 2008, marc wrote: > > > > On Sun, 28 Dec 2008, Yaser Sulaiman wrote: > > -- > David A. Black / Ruby Power and Light, LLC > Ruby/Rails consulting & training: [http://www.rubypal.com](http://www.rubypal.com) > Coming in 2009: The Well-Grounded Rubyist ([http://manning.com/black2\](http://manning.com/black2%5C)) ---
**Author:** ![Phlip1](https://avatars.discourse-cdn.com/v4/letter/p/df788c/32.png) [@Phlip1](https://rubytalk.org/u/Phlip1)\ **Post date:** [2 January 2009 08:11 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/13 "2009-01-02T08:11:36Z")
> 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'.) ---
**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\ **Post date:** [2 January 2009 12:42 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/14 "2009-01-02T12:42:16Z")
Hi -- > Phlip wrote: > > > Yaser Sulaiman 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. 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 > **路路路** > > On Fri, 2 Jan 2009, J枚rg W Mittag wrote: > > -- > David A. Black / Ruby Power and Light, LLC > Ruby/Rails consulting & training: [http://www.rubypal.com](http://www.rubypal.com) > Coming in 2009: The Well-Grounded Rubyist ([http://manning.com/black2\](http://manning.com/black2%5C)) > > [http://www.wishsight.com](http://www.wishsight.com) =\> Independent, social wishlist management! ---
**Author:** ![James\_Britt3](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@James\_Britt3](https://rubytalk.org/u/James_Britt3)\ **Post date:** [27 December 2008 23:16 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/15 "2008-12-27T23:16:05Z")
Martin DeMello wrote: > **路路路** > > > On Sat, Dec 27, 2008 at 8:49 PM, Robert Klemme \> \ wrote: > > > > > 2008/12/27 David A. Black \: > > > > > > > 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 Britt > > [www.happycamperstudios.com](http://www.happycamperstudios.com) - Wicked Cool Coding > [www.jamesbritt.com](http://www.jamesbritt.com) - Playing with Better Toys > [www.ruby-doc.org](http://www.ruby-doc.org) - Ruby Help & Documentation > [www.rubystuff.com](http://www.rubystuff.com) - The Ruby Store for Ruby Stuff ---
**Author:** ![marc1](https://avatars.discourse-cdn.com/v4/letter/m/49beb7/32.png) [@marc1](https://rubytalk.org/u/marc1)\ **Post date:** [28 December 2008 12:06 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/16 "2008-12-28T12:06:59Z")
David A. Black said... > Hi -- > > \> David A. Black said... > \>\> Hi -- > \>\> > \>\> > \>\>\> According to Wikipedia, a monkey patch[1] 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. > \>\> > \>\> 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. > \> > \> 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. 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. > **路路路** > > > On Sun, 28 Dec 2008, marc wrote: > > \>\> On Sun, 28 Dec 2008, Yaser Sulaiman wrote: > > -- > Cheers, > Marc ---
**Author:** ![GS1](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@GS1](https://rubytalk.org/u/GS1)\ **Post date:** [29 December 2008 09:29 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/17 "2008-12-29T09:29:49Z")
> \>\> 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 ---
**Author:** ![Forum](https://avatars.discourse-cdn.com/v4/letter/f/43a26b/32.png) [@Forum](https://rubytalk.org/u/Forum)\ **Post date:** [2 January 2009 15:10 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/18 "2009-01-02T15:10:36Z")
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 > **路路路** > > On Fri, Jan 2, 2009 at 1:42 PM, David A. Black \ wrote: > > > 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) > > -- > It is change, continuing change, inevitable change, that is the > dominant factor in society today. No sensible decision can be made any > longer without taking into account not only the world as it is, but > the world as it will be ... ~ Isaac Asimov ---
**Author:** ![ThoML](https://avatars.discourse-cdn.com/v4/letter/t/d78d45/32.png) [@ThoML](https://rubytalk.org/u/ThoML)\ **Post date:** [2 January 2009 16:32 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/19 "2009-01-02T16:32:26Z")
> 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. ---
**Author:** ![Michal\_Suchanek](https://avatars.discourse-cdn.com/v4/letter/m/e95f7d/32.png) [@Michal\_Suchanek](https://rubytalk.org/u/Michal_Suchanek)\ **Post date:** [3 January 2009 17:04 UTC](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895/20 "2009-01-03T17:04:08Z")
> Hi -- > > \> Phlip wrote: > \> > \> \> Yaser Sulaiman 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. > \> > > 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. That is not entirely true. For one the array has each\_with\_index but I could not find collect\_with\_index. If you look at the order of block arguments passed by each\_with\_index and implement collect\_with\_index the same way then if somebody else implements another one it must work the same or they did it wrong 馃槈 So if exact implementation of an extension can be logically deduced from existing functionality adding it should not break anything, Unfortunately it's rarely possible. > 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). The problem with this approach is that either you want it on 1-2 objects and then it's very local and the objects need not be strings anyway, you can just make a special object for the purpose. If you want strings that are used in particular piece of code to be extended you can do it on the entry point(s). However, it's tedious and error-prone this way. (The concern about changing the strings is not in place here if you gsub! them anyway, and you can dup) The problem is that if the strings ever leave your code they are still patched so in the end patching \*all\* strings in some way seems the cleanest possible solution. Perhaps by adding a different method like gsub!! or gsub!non\_nil (assuming at least one is a valid identifier). That's why some sort of namespacing was requested so many times. It makes patching in methods so much cleaner - only you would see the methods you have added or modified. Thanks Michal > **路路路** > > On 02/01/2009, David A. Black \ wrote: > > > On Fri, 2 Jan 2009, J枚rg W Mittag wrote: [Next page](https://rubytalk.org/t/what-does-monkey-patching-exactly-mean-in-ruby/50895.md?page=2)