From: "Peña, Botp" <botp@...>
Date: 2005-03-10T21:00:19+09:00
Subject: Re: Module#dup and Module.remove_method question

Renald Buter [mailto:buter@cwts.leidenuniv.nl] wrote:
//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?

imho, if you extend it further, you might see light.

>> module A
>>   def self.foo; puts "module A :: method foo"; end
>> end
=> nil
>>
?> X = A.dup
=> X
>> X.foo
module A :: method foo
=> nil
>>
?> class <<A; remove_method :foo; end
=> #<Class:A>
>>
?> A.foo
NoMethodError: undefined method `foo' for A:Module
        from (irb):10
>> X.foo
module A :: method foo
=> nil
>>
?> Y = A.dup
=> Y
>> Y.foo
NoMethodError: undefined method `foo' for Y:Module
        from (irb):14
>> Z = X.dup
=> Z
>> Z.foo
module A :: method foo
=> nil


As nuby, i can guess some benefits for this:

1. I retain visibility of inheritance of my inherited methods. I know ::foo
came from A::. Even though A (because of ruby's dynamicity) may change
anytime and may undef ::foo.

2. Pluggability (it's just my term; don't know oo :)). I plug and unplug
methods when/whereever I can (i'm thinking like children's lego blocks)

3. As shown in Y above; I want Y to behave like A but without foo. 

4. If I want something like original A (ie when it had foo). I just copy fr
X :-)

5. Hmmm... i think 3 & 4 describes my term of pluggability :-)

//
//Just curious...
//
//Renald
//

kind regards -botp