Renald Buter
3/10/2005 2:01:00 PM
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 :-)
>
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