From: Tom Werner Date: 2006-07-15T06:06:05+09:00 Subject: Re: Preferred monkeypatching technique Daniel Schierbeck wrote: > Tom Werner wrote: >> Allow me to present a scenario: >> >> class Firetruck >> def put_out_fire(options = {}) >> # code >> end >> end >> >> Pretend Firetruck is in a 3rd party application (like Rails) that is >> happy to allow plugins to modify core code. Now, let's say I want to >> write some code that always adds a certain attribute to the options >> hash. I could do this: >> >> class Firetruck >> alias_method :__old_put_out_fire, :put_out_fire >> def put_out_fire(options = {}) >> __old_put_out_fire(options.merge({:nozzle => :big})) >> end >> end >> >> Which works just fine until someone else comes up with a plugin that >> wants to modify the same method (doing something similar to me) and >> just so happens to also use :__old_put_out_fire as THEIR alias. Now >> we've got my plugin's method as the alias calling itself, which leads >> to, you know, badness. >> >> So I'm wondering if there's a better way. Perhaps some way to turn >> Firetruck into an ancestor of itself, so to speak, so that my plugin >> would create a new Firetruck class, pushing the old Firetruck >> backward in the chain and allowing me to call super instead and >> preventing alias_method explosions. Or would that just end up causing >> more havoc? > > Not a solution, but: > > > > cut MyCut < Firetruck > def put_out_fire(options = {}) > super(options.merge(:nozzle => :big)) > end > end > > (Trans, can I omit the `MyCut <' part?) > > > Cheers, > Daniel > > I looked at that RCR a while back, but only glanced over it as it was not applicable to my situation at the time. Looking at it again, I see the beauty and power in it. I would love to see that end up in 2.0! Tom -- Tom Werner Helmets to Hardhats Software Developer tom@helmetstohardhats.org www.helmetstohardhats.org