From: "David A. Black" <dblack@...>
Date: 2005-03-10T20:12:33+09:00
Subject: Re: Module#dup and Module.remove_method question

Hi --

On Thu, 10 Mar 2005, Renald Buter wrote:

> On 23:06 Wed 09 Mar     , David A. Black wrote:
>> Hi --
>>
>> On Wed, 9 Mar 2005, Renald Buter wrote:
>>
>> B.foo lives in A (the methods don't get dup'd when the class object is
>> dup'd), and to remove it from B you can use undef_method.
>> remove_method will only operate on the module where the method was
>> defined, whereas undef_method will take it out of the search path of
>> any module that could see it before.
>>
>
> Thank you very much for you answer, but it's still not clear to me: I
> *have* removed the method from A, yet B can still access it. How's that
> possible? Is it now a dangling method of some kind?

Now that I look at it again...  I think it must be special handling of
Class objects.  In the general case, a dup'd object doesn't see the
singleton methods of the original object:

   irb(main):006:0> x = Object.new
   => #<Object:0x40292b40>
   irb(main):007:0> def x.foo; "hi"; end
   => nil
   irb(main):008:0> y = x.dup
   => #<Object:0x40288dd4>
   irb(main):009:0> y.foo
   NoMethodError: undefined method `foo' for #<Object:0x40288dd4>

So, if it's set up to work differently for classes, I would then
assume that your class B (the dup) is given its own reference to
A.foo, and that that reference persists even though A itself can no
longer call foo.

I don't know whether this is by design or is some kind of side-effect
of some of the other special-case handling of Class objects (such as
inheritance, which also allows one object automatic access to the
singleton methods of another).


David

-- 
David A. Black
dblack@wobblini.net