Comments on: Other ways to wrap a method http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/ Random Geek-Related Thoughts Wed, 08 Sep 2010 23:53:11 -0700 hourly 1 By: Utilisation des modules Ruby à la place des fameux alias_method_chain http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-16302 Utilisation des modules Ruby à la place des fameux alias_method_chain Mon, 13 Apr 2009 07:31:13 +0000 http://yehudakatz.com/?p=196#comment-16302 [...] sur un article intéressant sur le blog de Jan Wedekind s’inspirant lui même de celui de Yehuda Katz. Celui ci décrit une façon de redéfinir une méthode plus “Ruby Way” que [...] [...] sur un article intéressant sur le blog de Jan Wedekind s’inspirant lui même de celui de Yehuda Katz. Celui ci décrit une façon de redéfinir une méthode plus “Ruby Way” que [...]

]]> By: Konstantin Haase http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-16196 Konstantin Haase Sun, 22 Mar 2009 13:47:48 +0000 http://yehudakatz.com/?p=196#comment-16196 I just wanted to let you now, that I wrote a script (in ruby!) that does something like "the best of all worlds ( without a caveat)": http://github.com/rkh/chainable I just wanted to let you now, that I wrote a script (in ruby!) that does something like “the best of all worlds ( without a caveat)”:

http://github.com/rkh/chainable

]]> By: Greg Spurrier http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-15639 Greg Spurrier Tue, 27 Jan 2009 19:11:30 +0000 http://yehudakatz.com/?p=196#comment-15639 I like the idea of explicitly declaring a method as chainable. My question, though, is how to you test/spec the wrapped method? With AMC, I usually stub or mock the aliased original method to make sure it is getting invoked as expected from within the wrapper. How do you do that when you are invoking it via super? I like the idea of explicitly declaring a method as chainable.

My question, though, is how to you test/spec the wrapped method? With AMC, I usually stub or mock the aliased original method to make sure it is getting invoked as expected from within the wrapper. How do you do that when you are invoking it via super?

]]> By: Gabriel Horner http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-15550 Gabriel Horner Tue, 20 Jan 2009 19:41:48 +0000 http://yehudakatz.com/?p=196#comment-15550 Nice writeup. I think there's a typo when you first introduced the chainable method. 'def chainable' should be 'def bar'. On a related note, I just released a gem to easily alias methods/classes when in irb: http://github.com/cldwalker/alias/tree/master Nice writeup. I think there’s a typo when you first introduced the chainable method. ‘def chainable’ should be ‘def bar’. On a related note, I just released a gem to easily alias methods/classes when in irb: http://github.com/cldwalker/alias/tree/master

]]> By: Alex P http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-15546 Alex P Tue, 20 Jan 2009 15:26:54 +0000 http://yehudakatz.com/?p=196#comment-15546 maybe I am missing something, but why do you need to include module inside override def override(&blk) mod = Module.new do extend TrackAddedMethods end mod.class_eval(&blk) __move_to_module(*mod.__added_methods) include mod end it looks like it is already included by __move_to_module... Am I missing something? maybe I am missing something, but why do you need to include module inside override
def override(&blk)
mod = Module.new do
extend TrackAddedMethods
end
mod.class_eval(&blk)
__move_to_module(*mod.__added_methods)
include mod
end

it looks like it is already included by __move_to_module… Am I missing something?

]]> By: Antares Trader http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-15527 Antares Trader Mon, 19 Jan 2009 01:13:45 +0000 http://yehudakatz.com/?p=196#comment-15527 @Ted Han: Have a look at Extlib::Hook for general purpose before and after hooks. As Yahuda pointed out in another post the library lacks conditionals filters, but so does AMC. because hooks work on a per method basis there is really nothing to be done about filters, but I know conditional can be added. The only question in my mind is how expensive they will be. @Ted Han: Have a look at Extlib::Hook for general purpose before and after hooks. As Yahuda pointed out in another post the library lacks conditionals filters, but so does AMC. because hooks work on a per method basis there is really nothing to be done about filters, but I know conditional can be added. The only question in my mind is how expensive they will be.

]]> By: Ted Han http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-15521 Ted Han Sun, 18 Jan 2009 17:33:33 +0000 http://yehudakatz.com/?p=196#comment-15521 Crazy stuff Yehuda! So, i don't know the MRI internals well enough to judge whether this is a good idea from an implementational standpoint. I've got a comment and a question. I've always wanted more powerful hooks in Ruby. I think it'd be cool to have the ability (before or after) a class or a method is defined or added to an object, to be able to manipulate that method, object or the host/parent in which the object is defined. This sort of looks like a step in that direction (although not general purpose yeh?). Further to that, how do you access prior versions of a method? (Yehuda answered this question for me elsewhere. You've still got access to the ancestor chain of methods via 'super', so if you wanted any of the intermediate definitions of a method, you can get at 'em, if you know the order in which they were added). Crazy stuff Yehuda!

So, i don’t know the MRI internals well enough to judge whether this is a good idea from an implementational standpoint. I’ve got a comment and a question.

I’ve always wanted more powerful hooks in Ruby. I think it’d be cool to have the ability (before or after) a class or a method is defined or added to an object, to be able to manipulate that method, object or the host/parent in which the object is defined.

This sort of looks like a step in that direction (although not general purpose yeh?).

Further to that, how do you access prior versions of a method?

(Yehuda answered this question for me elsewhere. You’ve still got access to the ancestor chain of methods via ‘super’, so if you wanted any of the intermediate definitions of a method, you can get at ‘em, if you know the order in which they were added).

]]> By: Yehuda Katz http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-15520 Yehuda Katz Sun, 18 Jan 2009 17:11:24 +0000 http://yehudakatz.com/?p=196#comment-15520 @teamon this technique can easily work on jruby @iain the issue I have with amc is that it's a very leaky abstraction. The goal here is to make an abstraction that is much less leaky so that the implementation doesn't *matter*. If you go look at the implementation of alias_method you'll see that it's quite complex, but you don't *have* to look at it because it works perfectly 100% of the time. @teamon this technique can easily work on jruby

@iain the issue I have with amc is that it’s a very leaky abstraction. The goal here is to make an abstraction that is much less leaky so that the implementation doesn’t *matter*. If you go look at the implementation of alias_method you’ll see that it’s quite complex, but you don’t *have* to look at it because it works perfectly 100% of the time.

]]> By: iain http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-15518 iain Sun, 18 Jan 2009 11:22:53 +0000 http://yehudakatz.com/?p=196#comment-15518 I do like alias_method_chain. If you know how it works, it is easy to find the methods it uses. If you see a method name =~ /\w_with_\w/ or /\w_without_\w/, you can recognize what has been done. It is very transparent imho. I don't like specifying your old method to be overridable, for the reason you mentioned. It sounds more natural for me to say to the overriding method that it's overriding something. But it might be because I'm used to it. What about: class Foo def bar 1 end override :bar do |old_bar| old_bar 1 end end I have of course no idea about it's implementation. Unfortunately ruby 1.8 doesn't support blocks this way... I do like alias_method_chain. If you know how it works, it is easy to find the methods it uses. If you see a method name =~ /\w_with_\w/ or /\w_without_\w/, you can recognize what has been done. It is very transparent imho. I don’t like specifying your old method to be overridable, for the reason you mentioned. It sounds more natural for me to say to the overriding method that it’s overriding something. But it might be because I’m used to it. What about:

class Foo
def bar
1
end
override :bar do |old_bar|
old_bar 1
end
end

I have of course no idea about it’s implementation. Unfortunately ruby 1.8 doesn’t support blocks this way…

]]> By: teamon http://yehudakatz.com/2009/01/18/other-ways-to-wrap-a-method/comment-page-1/#comment-15516 teamon Sun, 18 Jan 2009 10:16:03 +0000 http://yehudakatz.com/?p=196#comment-15516 What about jruby? What about jruby?

]]>