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.