On 7/19/06, transfire / gmail.com <transfire / gmail.com> wrote:
>
> Sean O'Halpin wrote:
> > On 7/18/06, Trans <transfire / gmail.com> wrote:
> > >
> > > On a side note I think I found a bug in Ruby, maybe
> > >
> > >   class X
> > >     def self.method_added(name)
> > >       p name
> > >     end
> > >   end
> > >
> > >   class X
> > >     def x; end
> > >    end
> > >    => :x
> > >
> > >   class << X
> > >     undef_method :method_added
> > >   end
> > >
> > >   class X
> > >     def y; end
> > >   end
> > >   => NoMethodError: undefined method `method_added' for X:Class
> > >
> > >
> > > </Trans>
> > >
> > >
> > Is it a bug? You are undef'ing it after all. remove_method would seem
> > more appropriate in this use case.
> >
> > But maybe a warning like "undefining `method_added' may cause serious
> > problem" like for __send__, __id__, etc. might be in order.
>
> Weel, yea sort of. B/c look at what happended to me. I defined my own
> method_added in a paritcular class, and in order to prevent an infinite
> loop I need to undefine it in a subclass of it. I.e.
>
>   class X
>     def method_added
>       ... this might define a method in a Y
>     end
>   end
>
>   class Y < X
>     remove_method :method_added  # goes right back to infinite loop
>     undef_method :method_added     # bombs per our "bug"
>     def method_added; end                # what I ended up with
>   end
>
> So there's an easy fix but it's seems a bit wasteful. One wuould expect
> undef to work and save a call to a noop. Butmaybe it's more efficeint
> to just make the call to the noop then it is to see if it's present? I
> somehow doubt it though. In whihc case I say it's a minor bug.
>
> T.
>
Having thought about it a bit more, I'm inclined to agree. There's no
(logical) reason why method_added should be called if you don't define
it yourself, so it seems reasonable to be able to undef it completely
from a class without side-effects.

Regards,
Sean