Bug in Kernel#method objects that call super?

I posted this to ruby-core and got a somewhat mixed response. I'm curious what the rest of you might think of this behavior.

···

-------- Original Message --------
Subject: Bug in Kernel#method objects that call super?
Date: Sat, 07 Jul 2007 05:57:13 +0900
From: Charles Oliver Nutter <charles.nutter@sun.com>
Reply-To: ruby-core@ruby-lang.org
To: ruby-core@ruby-lang.org

This seems very wrong to me. Calling through a method object should
behave the same for super as calling directly or calling through an alias:

class Foo
   def a; puts 'Foo a'; end
   def b; puts 'Foo b'; end
end

class Bar < Foo
   def a; puts 'Bar a'; super; end
   alias b a
end

Bar.new.a # => "Bar a\nFoo a"
Bar.new.b # => "Bar a\nFoo a"
Bar.new.method(:b).call # => "Bar a\nFoo b"

It seems incorrect for method objects to change the behavior of super.
If I super in 'a', I want super's 'a' to be called, without exception.

Can someone confirm this is a bug? In JRuby we always super up the
same-named chain, so this represents an incompatibility.

- Charlie

HI --

···

On Tue, 10 Jul 2007, Charles Oliver Nutter wrote:

This seems very wrong to me. Calling through a method object should
behave the same for super as calling directly or calling through an alias:

class Foo
def a; puts 'Foo a'; end
def b; puts 'Foo b'; end
end

class Bar < Foo
def a; puts 'Bar a'; super; end
alias b a
end

Bar.new.a # => "Bar a\nFoo a"
Bar.new.b # => "Bar a\nFoo a"
Bar.new.method(:b).call # => "Bar a\nFoo b"

It seems incorrect for method objects to change the behavior of super.
If I super in 'a', I want super's 'a' to be called, without exception.

I agree that it's very odd that the two ways of calling behave
differently. A secondary question is whether the #method behavior --
the dynamic calculation of what method super should look for -- has
any useful application. I can't think of any. Maybe we need "super!"
:slight_smile:

David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
   RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
     & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

me too.

-a

···

On Jul 9, 2007, at 9:31 AM, Charles Oliver Nutter wrote:

This seems very wrong to me

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama

I think the bug is in alias and not in #method ....

Or at least the bug is brought about by some odd interaction between
alias and #method. My WAG at the problem is that alias creates a copy
of the method :a and renames it method :b in Bar. There is some hint
in the lookup table in class Bar that tells the Ruby interpreter --
"hey, this is really method :a, so super should redirect to method :a
in the superclass".

When #method generates the Proc object, this hinting is not preserved.
So, when super is called, it redirects to method :b in Foo.

Again, just my WAG -- I have not looked at the source code on this one.

Blessings,
TwP

···

On 7/9/07, Charles Oliver Nutter <charles.nutter@sun.com> wrote:

I posted this to ruby-core and got a somewhat mixed response. I'm
curious what the rest of you might think of this behavior.

-------- Original Message --------
Subject: Bug in Kernel#method objects that call super?
Date: Sat, 07 Jul 2007 05:57:13 +0900
From: Charles Oliver Nutter <charles.nutter@sun.com>
Reply-To: ruby-core@ruby-lang.org
To: ruby-core@ruby-lang.org

This seems very wrong to me. Calling through a method object should
behave the same for super as calling directly or calling through an alias:

class Foo
   def a; puts 'Foo a'; end
   def b; puts 'Foo b'; end
end

class Bar < Foo
   def a; puts 'Bar a'; super; end
   alias b a
end

Bar.new.a # => "Bar a\nFoo a"
Bar.new.b # => "Bar a\nFoo a"
Bar.new.method(:b).call # => "Bar a\nFoo b"

It seems incorrect for method objects to change the behavior of super.
If I super in 'a', I want super's 'a' to be called, without exception.

Can someone confirm this is a bug? In JRuby we always super up the
same-named chain, so this represents an incompatibility.

dblack@wobblini.net wrote:

I agree that it's very odd that the two ways of calling behave
differently. A secondary question is whether the #method behavior --
the dynamic calculation of what method super should look for -- has
any useful application. I can't think of any. Maybe we need "super!"
:slight_smile:

I can't really think of any either; if you want that sort of polymorphism on a superclass, you shouldn't use super.

- Charlie