//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
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 <<X; def foo; A.foo; end; end
Hell, of course I can live with this, but it stil feels like some kind of
trade-off
Regards,
Renald
···
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; 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
