Re: What does 'Monkey Patching' exactly Mean in Ruby?

On 27.12.2008 16:17, Yaser Sulaiman wrote:
> [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:

<disclaimer>I am by no means authoritative for the subject.</disclaimer>

> 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

-- 
remember.guy do |as, often| as.you_can - without end