From: "T. Onoma" <transami@...>
Date: 2003-12-18T01:47:49+09:00
Subject: Re: UnboundMethods Useless?

On Wednesday 17 December 2003 04:17 pm, Peter wrote:
> >  before trying to change ruby, try first to understand it.
>
> Before we start calling each other names, I need a clarification. I can do
> this in Ruby:
>
>   class A
>   end
>
>   class B < A
>     def m
>       <some code>
>     end
>   end
>
>   class A
>     def m
>       <some code>
>     end
>   end
>
> Where <some code> twice represents the same bit of Ruby code. Nobody can
> keep me from doing the above. If I understand correctly, Ruby doesn't
> allow the method to be copied from B to A, only from A to B. Now the
> reason you say that Ruby's test is correct, and it rightfully prevents us
> from copying a method from B to A, is that because the above Ruby code
> doesn't make sense, or because Ruby somehow internally fixes method m for
> use in B such that it is no longer fit to be used in A? Or rephrased, is
> it because moving the code is wrong at the Ruby level, or at the
> underlying implementation level?

"Ruby somehow internally fixes method m for use in B such that it is no longer 
fit to be used in A" -- This much is certain as has been demonstrated. 
Although I do not know to what extent it does so.

As for being wrong at the Ruby level, I am willing to accept that. As David 
pointed out, by your own suggestion, modules are intended for this use. It is 
in fact possible to make an annonyomous module, add a method to it, and add 
the module to any class. So there is a perfectly good mechinism. The 
weakness, as matz pointed out, is that it is not a Dynamic inclusion.

But I do wonder, if one can do this using module containers, how much of a 
stretch is it to allow the same thing on a method-by-method basis. Indeed one 
could be quite "tricky" and give every method it's own module.

-- 
T.