For example. Look the following piece of simple Ruby Code:
class ExampleClass
def some_instance_method
'Called some_instace_method!'
end
end
def ExampleClass.i_am_a_class_method
'Called i_am_a_class_method!'
end
inst = ExampleClass.new
def inst.i_am_an_instance_method
'Called i_am_an_instance_method'
end
Basically, I am reopening the definition of ExampleClass and adding another method. At first I am creating a new class method and afterwards I am creating a new instance method (for the object inst only). Is monkey patching the correct term for that kind of programming style?
How would you call this style of programming? I'm asking because I'm quite new to Ruby and currently trying to learn the right vocabulary to easily communicate with other Ruby programmers. I am definitely not looking for flame war!
That's really just open classes. The term Monkey Patching comes into
play when you're doing the same with classes you haven't written or
don't have control over, say String or Array.
class Array
def my_method
puts "hi"
end
end
array =
array.my_method # => "hi"
Jason
···
On 5/16/08, Christoph Schiessl <c.schiessl@gmx.net> wrote:
For example. Look the following piece of simple Ruby Code:
class ExampleClass
def some_instance_method
'Called some_instace_method!'
end
end
def ExampleClass.i_am_a_class_method
'Called i_am_a_class_method!'
end
inst = ExampleClass.new
def inst.i_am_an_instance_method
'Called i_am_an_instance_method'
end
Basically, I am reopening the definition of ExampleClass and adding another
method. At first I am creating a new class method and afterwards I am
creating a new instance method (for the object inst only). Is monkey
patching the correct term for that kind of programming style?
How would you call this style of programming? I'm asking because I'm quite
new to Ruby and currently trying to learn the right vocabulary to easily
communicate with other Ruby programmers. I am definitely not looking for
flame war!
Basically, I am reopening the definition of ExampleClass and adding
another method. At first I am creating a new class method and afterwards
I am creating a new instance method (for the object inst only). Is
monkey patching the correct term for that kind of programming style?
Yes and no. Monkey patching it is called, if one ignores potential side
effects, or performs something dangerous, like re-opening a a Core class.
How would you call this style of programming? I'm asking because I'm
quite new to Ruby and currently trying to learn the right vocabulary to
easily communicate with other Ruby programmers. I am definitely not
looking for flame war!
For example. Look the following piece of simple Ruby Code:
class ExampleClass
def some_instance_method
'Called some_instace_method!'
end
end
def ExampleClass.i_am_a_class_method
'Called i_am_a_class_method!'
end
inst = ExampleClass.new
def inst.i_am_an_instance_method
'Called i_am_an_instance_method'
end
Basically, I am reopening the definition of ExampleClass and adding another method. At first I am creating a new class method and afterwards I am creating a new instance method (for the object inst only). Is monkey patching the correct term for that kind of programming style?
How would you call this style of programming? I'm asking because I'm quite new to Ruby and currently trying to learn the right vocabulary to easily communicate with other Ruby programmers. I am definitely not looking for flame war!
Best regards,
Christoph Schiessl
I would suggest open classes, re-opening classes, and creating the so called 'singleton' classes (another debate there, you can easily search for discussions on it). The term "monkey patching" seems to come from the Python community, where it is not as openly accepted as it is here, and thus appears to carry a stronger negative connotation.
Actually, this code never reopens the definition of ExampleClass.
def ExampleClass.i_am_a_class_method
end
Doesn't reopen example class, it defines a method on the singleton
class (a.k.a metaclass) of the object bound to the global name
ExampleClass, which just happens to be a class, it doesn't really do
anything to the ExampleClassObject.
inst = ExampleClass.new
def inst.i_am_an_instance_method
end
Likewise doesn't touch the ExampleClass object at all either. It adds
a method to the singleton class of the object bound to the variable
inst.
I've skimmed the earlier responses and I don't think anyone else
pointed this out.
···
On Fri, May 16, 2008 at 2:27 PM, Christoph Schiessl <c.schiessl@gmx.net> wrote:
For example. Look the following piece of simple Ruby Code:
class ExampleClass
def some_instance_method
'Called some_instace_method!'
end
end
def ExampleClass.i_am_a_class_method
'Called i_am_a_class_method!'
end
inst = ExampleClass.new
def inst.i_am_an_instance_method
'Called i_am_an_instance_method'
end
Basically, I am reopening the definition of ExampleClass and adding another
method. At first I am creating a new class method and afterwards I am
creating a new instance method (for the object inst only). Is monkey
patching the correct term for that kind of programming style?
Yes and no. Monkey patching it is called, if one ignores potential side
effects, or performs something dangerous, like re-opening a a Core class.
Sorry Philip to disagree slightly, re-opening a Core class is not
dangerous it is potentially dangerous.
I would it call dangerous in libraries not applications and still
there are libraries specifically made to do this as e.g. Facets.
Ok as OP is a nuby maybe we might say dangerous after all, but not
tabou at least ;).
> How would you call this style of programming? I'm asking because I'm
> quite new to Ruby and currently trying to learn the right vocabulary to
> easily communicate with other Ruby programmers. I am definitely not
> looking for flame war!
Hey if you were looking for a flame war, this is not the best place
anyway ;), no worries your question is a sensitive one!
Actually, I disagree with both definitions. I don't consider opening and extending
Classes (be they core or not) monkey-patching.
I define monkey-patching as "opening and changing behaviour of a method/class
in the knowledge that other classes/libraries depend on it".
So
class Array
def my_funky_function
"this array is of the hook"
end
end
has nothing to do with monkey-patching - chances are high that there are no conflicts.
class Array
def =(elem) #whoops, i dropped the element
end
end
is a total different case. I postulate that most Programs written in Ruby depend on the behaviour
of Array#=. So this is monkey-patching at its worst. (you patch a certain functionality because
you think that it should behave differently. In this case, it is pretty obvious, that this try was a failure.
The wikipedia has a nice explanation:
"In Python, the term monkey patch only refers to dynamic modifications of a class at runtime based on the intent to patch existing methods in an external class as a workaround to a bug or feature which does not act as you desire. Other forms of modifying a class at runtime have different names, based on their different intents. For example, in Zope and Plone, security patches are often delivered using dynamic class modification, but they are called hot fixes.
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."
Regards
Florian Gilcher
···
On May 16, 2008, at 9:31 PM, Robert Dober wrote:
On Fri, May 16, 2008 at 8:58 PM, Phillip Gawlowski > <cmdjackryan@googlemail.com> wrote:
Yes and no. Monkey patching it is called, if one ignores potential side
effects, or performs something dangerous, like re-opening a a Core class.
Sorry Philip to disagree slightly, re-opening a Core class is not
dangerous it is potentially dangerous.
I would it call dangerous in libraries not applications and still
there are libraries specifically made to do this as e.g. Facets.
Ok as OP is a nuby maybe we might say dangerous after all, but not
tabou at least ;).
> How would you call this style of programming? I'm asking because I'm
> quite new to Ruby and currently trying to learn the right vocabulary to
> easily communicate with other Ruby programmers. I am definitely not
> looking for flame war!
Hey if you were looking for a flame war, this is not the best place
anyway ;), no worries your question is a sensitive one!
Nor do I, as Philip was kindly giving the link to the recent
discussion in which I have been more and more driven away from the
term MP, by the kind and thoughtful words of David Black I did not
want to repeat this POV.
<some other interesting stuff skipped>
Cheers
Robert
···
On Fri, May 16, 2008 at 9:48 PM, Florian Gilcher <flo@andersground.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Actually, I disagree with both definitions. I don't consider opening and
extending
Classes (be they core or not) monkey-patching.
I think this is one of the best definitions I've seen. It should be
remembered that the term arose in specific circumstances: it came from
the practice of dynamically modifying the behavior of *existing* code.
Hence "patching", rather than "monkey extending" or "monkey adding".
Of course, it's not as clear-cut as all that because sometimes one
coder's extension is another coder's unexpected change in behavior.
But the spirit of monkey patching is that of altering existing code so
that it behaves differently - to temporarily fix a bug without
altering the source, for instance.
···
On Fri, May 16, 2008 at 3:48 PM, Florian Gilcher <flo@andersground.net> wrote:
I define monkey-patching as "opening and changing behaviour of a
method/class
in the knowledge that other classes/libraries depend on it".
puts c.foo(42)
# bar 42 -- the new method ran over the old one
In a class-based OO language with open classes like ruby, I'd actually
expect that behaviour.
puts == 42
# false -- the new method was ignored
Array.respond_to?('==')
=> true
That's because of:
Object.method_defined?('==')
=> true
BTW I think you wanted to use method_defined?() or instance_method()
instead of respond_to?() which in your case refers to the class and
not to the instances thereof. In your example, you actually check if
there is a class method of that name and then define an instance
method.
