From: Bertram Scharpf <lists@...>
Date: 2005-03-10T23:34:43+09:00
Subject: Re: Module#dup and Module.remove_method question

Hi,

Am Donnerstag, 10. M�r 2005, 20:12:33 +0900 schrieb David A. Black:
> On Thu, 10 Mar 2005, Renald Buter wrote:
> >On 23:06 Wed 09 Mar     , David A. Black wrote:
> >>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.
> >
> >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:

I see the same behaviour:

    >> q = 'probscedian'
    => "probscedian"
    >> class <<q ; def snuffle ; end ; end
    => nil
    >> c = q.clone ; d = q.dup
    => "probscedian"
    >> [q,c,d].map do |x| x.singleton_methods end
    => [["snuffle"], ["snuffle"], []]
    >> module Q ; def Q.foo ; end ; end
    => nil
    >> C = Q.clone ; D = Q.dup
    => D
    >> [Q,C,D].map do |m| m.singleton_methods end
    => [["foo"], ["foo"], ["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).

I don't understand this either and would like to know
whether this behaviour is intended and if, then why.

Bertram


-- 
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de