This is something of a follow-up to Bruce Williams' wrap-up of "wrapping a method" approaches. Bruce covered two approaches:
alias_method_chain: rename the original method, then copy the new method over it and call the old one.
class Foo def bar 1 end alias_method :original_bar, :bar def bar original_bar + 1 end end
super and extend: override #new and extend the new object's metaclass with the method.
class Foo def bar 1 end module Incrementor def bar super + 1 end end def self.new super.extend Incrementor end end
I wanted to cover two other options, which come with more serious caveats than Bruce's approaches, but which have their benefits.
explicitly declaring a method as chainable: if you are in control of the code you want to extend, make it chainable from the beginning
class Foo chainable = Module.new do def bar 1 end end include chainable def chainable super + 1 end end
What's going on above is that instead of declaring the method on the class itself, we're sticking it into an (anonymous) module, then including the module into Foo. As a result, we can now define a method on Foo itself, and super to the module we included. We can even wrap up the idiom pretty simply:
class Module def overridable(&blk) mod = Module.new(&blk) include mod end end class Foo overridable do def bar 1 end end def bar super + 1 end end
I like this approach a lot, but it does require that you have control over the original code. In some cases (for instance, Rails chaining its own code via modules) that is the case. This approach, in my opinion, is superior to alias_method_chain because it does not mutate method names, so it eliminates the confusion of looking for a method from a stack trace on a certain line and finding a method with a different name. Also, having to explicitly declare a method chainable provides a cue to the reader of the code that the method is not complete, and that there might be other components elsewhere.
the best of all worlds (with a caveat): the best option would allow you the benefits of the approach immediately above without requiring that you declare the method chainable (so you could add advice to other peoples' code). The solution, unfortunately, requires a (rather crude) C extension I whipped up.
There are a few things going on above. The interesting part is the little bit of C code. This code lives on any Module. It grabs a method from the module's method table, and inserts it (with the same name) on any other Module. The TrackAddedMethods module can be extended onto any module, and it will remember all the methods that were added (using a method added hook).
override method uses the same technique as the chainable method above to create a new module with the methods inside of it. Only this time, as the methods get added, we track them. Each method that is added to the module is then removed from the class itself and moved up (via the C extension) to a module, which is then included into the base class. At this point, the base class doesn't have the method on it anymore, but the original method is included into the base class via a module.
At this point, we're at the same place as we would have been using the first technique I described above, so we simply include the module that was created from the override() method and voila: you can tweak someone else's methods without needing to rename them.
I hope the forgoing didn't blow anyone's minds. It blew mine the first time I started playing with it ;)