From: Renald Buter Date: 2005-03-10T23:00:31+09:00 Subject: Re: Module#dup and Module.remove_method question On 21:00 Thu 10 Mar , "Pe?a, Botp" wrote: > 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.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 :-) > That's the issue: you can't restore the old method-resolving behaviour in the duped object: say there is a parent of A that implements 'foo' also, there is now no way of calling that automatically in X, except through explicitly setting foo like: class <