From: Charles Oliver Nutter <charles.nutter@...>
Date: 2009-01-19T06:02:11+09:00
Subject: [ruby-core:21419] Re: Proposal: Module#copy_method

Not a whole lot, except that it causes another level of method searching 
(included anon module) for each such use, which will impact perf in MRI.

It does seem like the method-accepting form of define_method could be a 
little less restrictive (as you and I discussed online), allowing pure 
Ruby methods to be "copied" directly without Method#bind inheritance 
restrictions. Modifying Method#bind logic in JRuby in a similar way does 
allow this to work correctly:

module Foo
   def foo
     puts 'here'
   end
end

module Bar
   define_method(:a, Foo.instance_method(:foo))
end

include Bar
a # => prints 'here'

I think the tricky bit here is that modifying this Method#bind check 
could cause native methods to be moved to classes with different 
in-memory structure. Filtering out all native methods (as we discussed 
online) would be a necessity. I'm not sure if there's precedent for that 
kind of check currently.

Yehuda Katz wrote:
> So I guess the question is... what's wrong with the implementation ;)
> 
> -- Yehuda
> 
> On Sun, Jan 18, 2009 at 12:31 PM, Charles Oliver Nutter 
> <charles.nutter@sun.com <mailto:charles.nutter@sun.com>> wrote:
> 
>     Yehuda Katz wrote:
> 
>         AOP requires being able to hook into method dispatch, which
>         either requires a modification to core, or method transplanting.
>         Unless you see a different approach?
> 
> 
>     Not necessarily. Around can also be a bit of method logic that
>     simply aggregates the original method, like an alias with extra
>     logic. And of course you've essentially implemented "around"
>     behavior without modifying core, so there's bound to be other ways too.
> 
>     - Charlie
> 
> 
> 
> 
> -- 
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325