"itsme213" <itsme213 / hotmail.com> schrieb im Newsbeitrag 
news:NUe3e.22640$1H3.7060 / tornado.texas.rr.com...
> "Robert Klemme" <bob.news / gmx.net> wrote
>
>> From all that I know you can't because you cannot do any of these:
>>
>>  - bind an instance method of A to B (unless B is a superclass of A)
>>
>>  - convert a method to a proc that is usable with instance_eval.
>>
>> The question is: does it make sense to do that?
>
> How do you mean "make sense"?

"Does it make sense to steal a method from a class and make it execute on 
another classes instance?"  I mean, you cannot generally expect that all 
methods the "stolen" method requires are present in the other class.  (I 
know that's why you use the fallback but then again, what does one gain? 
You can, for exaple, inject methods temporarily into the other instance.)

> Does my desired behavior make sense (it does to me)?

Apparently. :-)  But in what use case do you need this?  Although Ruby is 
amazingly dynamic not all features we can think of actually make sense.

> Or does it make sense for Ruby to permit one of the 2 approaches you
> suggest (#2 does, not sure I understood #1)?
>
> Thanks.
>
> btw, my guess at what the instance_eval version might look like:
>
> class B
> def initialize delegatee
>   @a = delegatee
> end
> def method_missing sym, *args, &block
>  m = @a.method sym
>  self.instance_eval m, *args, &block
> end
> end

Won't work as far as  my experiements seem to indicate.

Here's another idea: how about copying instance state around?

Kind regards

    robert