From: "David A. Black" Date: 2009-09-18T05:06:34+09:00 Subject: Re: Monkey Patching 2 Methods, Overrides One Method, Not The Other --1926193751-1828584692-1253217976=:18642 Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-1828584692-1253217976=:18642" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1926193751-1828584692-1253217976=:18642 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Hi -- On Fri, 18 Sep 2009, MaggotChild wrote: > On Sep 17, 5:02�am, "David A. Black" wrote: >> Hi -- >> >> On Thu, 17 Sep 2009, MaggotChild wrote: >>> I'm monkey patching 2 methods of an existing module: some_method() and >>> another_method() >> >>> Calling some_method() on an instance of class that includes the >>> original module works fine (calls the monkey patched version), but >>> when I call another_method() the original (not the monkey patched) >>> method is called. >> >>> There is a lot of code, and I've tried to recreate the series of >>> includes with the below example, yet the example works! >> >>> Given this, I hope that someone could still provide me with some >>> insight as to why this would happen >> >> I'm never quite sure what people mean by "monkey patching" >> -- it always sounds like deliberately doing something badly, so that having >> it not work shouldn't be a surprise :-) > > It sure sounds like you understand what I mean, and I agree, yet the > problematic modules (mine and the one I'm attempting to override) are > filled with this sort of behavior and a full rewrite is not feasible > at this time. > > It's unfortunate that the Ruby community has adopted such an abhorrent > practice to the extent it has. > Furthermore, what sort of examples are we setting for the children who > take up Ruby as their first language. > > I hope that the The Well-Grounded Rubyist isn't advocating this sort > of OO flummory :^) I think we might be talking at cross-purposes. I dislike the term "monkey patching", partly because I never know quite what it means and partly because, whatever else it means, it stigmatizes practices that are, in their place, perfectly fine. It's not a criticism of your code. (I haven't even seen your code :-) >> Can you look at the difference between your real code and your >> example, and try to spot what's not working? > > I'd like to think that it has something to do with the way the modules > are required. In the real code there are far more `requires` and even > a `load`. > > I go back to my generalization of this problem: How can one module > revert back to its original implementation on one method and not the > other, when both the original and overridden methods are contained in > 1 file respectively? Ceteris paribus, it can't. So something's up that won't be duplicable in the stripped-down version. One suggestion is to think of it from the object's perspective: it's not that the module reverts to a former implementation, but that the old version has someone been positioned before the new one in the object's search path. If you track down exactly what class/module path the object is walking, you might be able to spot the difference. David -- David A. Black, Director Ruby Power and Light, LLC (http://www.rubypal.com) Ruby/Rails training, consulting, mentoring, code review Book: The Well-Grounded Rubyist (http://www.manning.com/black2) --1926193751-1828584692-1253217976=:18642-- --1926193751-1828584692-1253217976=:18642--