On 2 Jul 2003 at 17:14, nobu.nokada / softhome.net wrote:

> > But since I had some problems re-binding unbound 
> > methods lately I'm interested in this topic. So could someone try to 
> > explain it to me?
> 
> What problem?

When overriding a method, we normally use alias to save the old 
implementation under a new name, so that we can call it later. People 
are trying to find obscure names for the aliases to avoid naming 
conflicts.

I was trying to find a way to override a method without having to 
find a unique name. Instead I wanted to be able to simply call the 
old implementation with "super".

This is a simplified version of what I got (in Ruby 1.8):

  class Class
    def override( name )
      mod = Module.new
      mod.send( :define_method, name, instance_method( name ) )
      include mod
    end
  end

As you can see, this creates a module, "copies" the original method 
into the module, and finally includes the module. Now you can call 
the original implementation via "super":

  class C
    def m
      puts "original"
    end
  end

  C.new.m  # => original

  class C
    override :m
    def m
      puts "before(1)"
      super
    end
  end

  C.new.m  # => before(1), original

So far, so good. But if you do this one more time, you get:

  class C
    override :m
    def m
      puts "before(2)"
      super
    end
  end

  C.new.m  # => before(2), before(1), before(1), ...

So it seems that the methods which are moved into the new modules 
still "remember" that they originally were defined in class C, and 
when they call super they somehow restart the search in the first 
ancestor of C, not in the first ancestor of the module they are 
currently defined in.

I haven't had time yet to look further into this, but maybe you know 
what's going on here.

Regards,
Pit