From: Eric Hodel <drbrain@...7.net>
Date: 2006-07-14T08:45:59+09:00
Subject: Re: Preferred monkeypatching technique

On Jul 13, 2006, at 4:28 PM, 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?

You just described subclasses:

class BigNozzleFiretruck < Firetruck

   def put_out_fire(options = {})
     options = options.merge :nozzle => :big
     super options
   end

end

-- 
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com