ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
* [ruby-core:62202] [ruby-trunk - Feature #9781] [Open] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
@ 2014-04-28 22:07 ` richard.schneeman
  2014-04-28 22:23 ` [ruby-core:62203] [ruby-trunk - Feature #9781] " tenderlove
                   ` (23 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: richard.schneeman @ 2014-04-28 22:07 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been reported by Richard Schneeman.

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62203] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
  2014-04-28 22:07 ` [ruby-core:62202] [ruby-trunk - Feature #9781] [Open] Feature Proposal: Method#super_method richard.schneeman
@ 2014-04-28 22:23 ` tenderlove
  2014-04-29  1:59 ` [ruby-core:62206] " nobu
                   ` (22 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: tenderlove @ 2014-04-28 22:23 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Aaron Patterson.


I also have this problem especially when debugging code where modules are mixed in at runtime, so I have to do something like this:

~~~
class << obj; self; end.ancestors.find_all { |klass|
  klass.method_defined? :foo
}.map { |klass| klass.method(:foo).source_location }.last
~~~

(or something similar).  A method to get the "super method" would be very convenient.

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46355

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62206] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
  2014-04-28 22:07 ` [ruby-core:62202] [ruby-trunk - Feature #9781] [Open] Feature Proposal: Method#super_method richard.schneeman
  2014-04-28 22:23 ` [ruby-core:62203] [ruby-trunk - Feature #9781] " tenderlove
@ 2014-04-29  1:59 ` nobu
  2014-04-29  4:24 ` [ruby-core:62209] " charliesome
                   ` (21 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: nobu @ 2014-04-29  1:59 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Nobuyoshi Nakada.

Description updated

A patch.
No tests yet.

~~~diff
diff --git a/proc.c b/proc.c
index 8153cc9..d1db478 100644
--- a/proc.c
+++ b/proc.c
@@ -1481,11 +1481,17 @@ method_owner(VALUE obj)
     return defined_class;
 }
 
-void
-rb_method_name_error(VALUE klass, VALUE str)
+struct method_name_error {
+    VALUE class_name;
+    const char *type;
+};
+
+static struct method_name_error
+prepare_method_name_error(VALUE klass)
 {
     const char *s0 = " class";
     VALUE c = klass;
+    struct method_name_error e;
 
     if (FL_TEST(c, FL_SINGLETON)) {
 	VALUE obj = rb_ivar_get(klass, attached);
@@ -1500,8 +1506,22 @@ rb_method_name_error(VALUE klass, VALUE str)
     else if (RB_TYPE_P(c, T_MODULE)) {
 	s0 = " module";
     }
-    rb_name_error_str(str, "undefined method `%"PRIsVALUE"' for%s `%"PRIsVALUE"'",
-		      QUOTE(str), s0, rb_class_name(c));
+    e.class_name = rb_class_name(c);
+    e.type = s0;
+    return e;
+}
+
+#define method_name_error(klass, str, t) do { \
+	struct method_name_error e = prepare_method_name_error(klass); \
+	rb_name_error_str(str, t" method `%"PRIsVALUE"' for%s `%"PRIsVALUE"'", \
+			  QUOTE(str), e.type, e.class_name); \
+    } while (0)
+
+
+void
+rb_method_name_error(VALUE klass, VALUE str)
+{
+    method_name_error(klass, str, "undefined");
 }
 
 /*
@@ -2430,6 +2450,23 @@ method_proc(VALUE method)
     return procval;
 }
 
+static VALUE
+method_super_method(VALUE method)
+{
+    struct METHOD *data;
+    VALUE defined_class, super_class;
+
+    TypedData_Get_Struct(method, struct METHOD, &method_data_type, data);
+    defined_class = data->defined_class;
+    if (BUILTIN_TYPE(defined_class) == T_MODULE) defined_class = data->rclass;
+    super_class = RCLASS_SUPER(defined_class);
+    if (!super_class) {
+	method_name_error(defined_class, rb_id2str(data->id), "no superclass");
+    }
+    return mnew(super_class, data->recv, data->id,
+		rb_obj_class(method), FALSE);
+}
+
 /*
  * call-seq:
  *   local_jump_error.exit_value  -> obj
@@ -2735,6 +2772,7 @@ Init_Proc(void)
     rb_define_method(rb_cMethod, "unbind", method_unbind, 0);
     rb_define_method(rb_cMethod, "source_location", rb_method_location, 0);
     rb_define_method(rb_cMethod, "parameters", rb_method_parameters, 0);
+    rb_define_method(rb_cMethod, "super_method", method_super_method, 0);
     rb_define_method(rb_mKernel, "method", rb_obj_method, 1);
     rb_define_method(rb_mKernel, "public_method", rb_obj_public_method, 1);
     rb_define_method(rb_mKernel, "singleton_method", rb_obj_singleton_method, 1);
@@ -2756,6 +2794,7 @@ Init_Proc(void)
     rb_define_method(rb_cUnboundMethod, "bind", umethod_bind, 1);
     rb_define_method(rb_cUnboundMethod, "source_location", rb_method_location, 0);
     rb_define_method(rb_cUnboundMethod, "parameters", rb_method_parameters, 0);
+    rb_define_method(rb_cUnboundMethod, "super_method", method_super_method, 0);
 
     /* Module#*_method */
     rb_define_method(rb_cModule, "instance_method", rb_mod_instance_method, 1);
~~~


----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46358

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* [ruby-core:62209] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (2 preceding siblings ...)
  2014-04-29  1:59 ` [ruby-core:62206] " nobu
@ 2014-04-29  4:24 ` charliesome
  2014-04-30  7:13 ` [ruby-core:62243] " ko1
                   ` (20 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: charliesome @ 2014-04-29  4:24 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Charlie Somerville.


I would also find this feature very useful when debugging large code bases with complicated class/module hierarchies.

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46361

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62243] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (3 preceding siblings ...)
  2014-04-29  4:24 ` [ruby-core:62209] " charliesome
@ 2014-04-30  7:13 ` ko1
  2014-04-30 16:35 ` [ruby-core:62253] " nobu
                   ` (19 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ko1 @ 2014-04-30  7:13 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Koichi Sasada.


What should happen on `#call' method with method objects returned from super_method?


----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46394

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62253] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (4 preceding siblings ...)
  2014-04-30  7:13 ` [ruby-core:62243] " ko1
@ 2014-04-30 16:35 ` nobu
  2014-04-30 17:04   ` [ruby-core:62254] " SASADA Koichi
  2014-04-30 17:11 ` [ruby-core:62255] " ko1
                   ` (18 subsequent siblings)
  24 siblings, 1 reply; 26+ messages in thread
From: nobu @ 2014-04-30 16:35 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Nobuyoshi Nakada.


It's an ordinary `Method` (or `UnboundMethod`) instance, same as `SuperClass.instance_method(:foo).bind(obj)`.


----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46414

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62254] Re: [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
  2014-04-30 16:35 ` [ruby-core:62253] " nobu
@ 2014-04-30 17:04   ` SASADA Koichi
  0 siblings, 0 replies; 26+ messages in thread
From: SASADA Koichi @ 2014-04-30 17:04 UTC (permalink / raw
  To: ruby-core

(2014/05/01 1:35), nobu@ruby-lang.org wrote:
> 
> It's an ordinary `Method` (or `UnboundMethod`) instance, same as `SuperClass.instance_method(:foo).bind(obj)`.

Oh, OK. I misunderstood the spec of Method class.


-- 
// SASADA Koichi at atdot dot net

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62255] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (5 preceding siblings ...)
  2014-04-30 16:35 ` [ruby-core:62253] " nobu
@ 2014-04-30 17:11 ` ko1
  2014-05-01 23:10 ` [ruby-core:62272] " ryand-ruby
                   ` (17 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ko1 @ 2014-04-30 17:11 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Koichi Sasada.


 (2014/05/01 1:35), nobu@ruby-lang.org wrote:
 > 
 > It's an ordinary `Method` (or `UnboundMethod`) instance, same as `SuperClass.instance_method(:foo).bind(obj)`.
 
 Oh, OK. I misunderstood the spec of Method class.
 
 
 -- 
 // SASADA Koichi at atdot dot net

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46416

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62272] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (6 preceding siblings ...)
  2014-04-30 17:11 ` [ruby-core:62255] " ko1
@ 2014-05-01 23:10 ` ryand-ruby
  2014-05-02  2:43 ` [ruby-core:62275] " ruby-core
                   ` (16 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ryand-ruby @ 2014-05-01 23:10 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Ryan Davis.


Maybe it is just me misunderstanding something... but this doesn't seem that complicated. I don't understand why you'd walk through the ancestors when you just just ask one level up:

~~~ruby
class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end

class Object
  def super_method name
    self.class.superclass.instance_method name
  end
end

p Foo.new.method(:bar).source_location.last                           # => 7
p Foo.new.class.superclass.instance_method(:bar).source_location.last # => 2
p Foo.new.super_method(:bar).source_location.last                     # => 2
~~~

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46435

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62275] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (7 preceding siblings ...)
  2014-05-01 23:10 ` [ruby-core:62272] " ryand-ruby
@ 2014-05-02  2:43 ` ruby-core
  2014-05-02  3:03 ` [ruby-core:62276] " ruby-core
                   ` (15 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ruby-core @ 2014-05-02  2:43 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Marc-Andre Lafortune.


Hi,

Ryan Davis wrote:
> Maybe it is just me misunderstanding something... but this doesn't seem that complicated. I don't understand why you'd walk through the ancestors when you just just ask one level up:

For one level, with simple class inheritance, it probably isn't, but throw in a prepended module or two, and the desire to go up more than one level (i.e. `obj.method(:foo).super_method.super_method`) and it's not completely trivial.

If ever we support a module being included more than once in the ancestry chain, then it's actually impossible (unless Method provides a more extensive api to tell where it is in the ancestry chain).

I'm +1 for this feature, although I would favor the shorter name `super`. I don't think it would ever conflict with the keyword, and if it did there is still the same solution as with `class`, i.e. `self.super`.

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46439

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62276] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (8 preceding siblings ...)
  2014-05-02  2:43 ` [ruby-core:62275] " ruby-core
@ 2014-05-02  3:03 ` ruby-core
  2014-05-02  3:14 ` [ruby-core:62277] " ruby-core
                   ` (14 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ruby-core @ 2014-05-02  3:03 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Marc-Andre Lafortune.


Nobuyoshi Nakada wrote:
> It's an ordinary `Method` (or `UnboundMethod`) instance, same as `SuperClass.instance_method(:foo).bind(obj)`.

Agreed for `Method`, but I'm not sure I understand how we could define `UnboundMethod#super_method`, since a Module can be part of different ancestry chains.

    # same example as original post continued
    module M
      def bar
      end
    end
    Foo.include bar

    Foo.ancestors # => [Foo, M, BigFoo, ...]
    Foo.new.method(:bar).super_method.super_method.owner # => BigFoo
    Foo.instance_method(:bar).super_method.super_method.owner # => Can't possible give meaningful result
    
(I didn't try the patch)

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46440

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62277] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (9 preceding siblings ...)
  2014-05-02  3:03 ` [ruby-core:62276] " ruby-core
@ 2014-05-02  3:14 ` ruby-core
  2014-05-02  8:47 ` [ruby-core:62285] " ryand-ruby
                   ` (13 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ruby-core @ 2014-05-02  3:14 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Marc-Andre Lafortune.


I must be tired.

Nobu: Sorry, I was confused, there's no problem with `UnboundMethod#super_method` because we retain which class this method was accessed from.

Ryan: That's actually a good example, there is no api to get the "original owner" of an unbound method, so in general it's not possible to implement `super_method` in Ruby. E.g. from `Hash.instance_method(:map)`, I don't know of a way to get back `Hash` in pure Ruby, and thus no way to go through Hash's ancestry chain.



----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46441

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62285] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (10 preceding siblings ...)
  2014-05-02  3:14 ` [ruby-core:62277] " ruby-core
@ 2014-05-02  8:47 ` ryand-ruby
  2014-05-02 15:02 ` [ruby-core:62295] " richard.schneeman
                   ` (12 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ryand-ruby @ 2014-05-02  8:47 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Ryan Davis.


Maybe I'm still not getting something. If you can call it (or super to it) you can grab it:

~~~ruby
class BigFoo
  def bar
  end
end

class Middle1 < BigFoo; end
class Middle2 < Middle1; end
class Middle3 < Middle2; end
class Middle4 < Middle3; end
class Middle5 < Middle4; end

class Foo < Middle5
  def bar
    super
  end
end

class Object
  def super_method name
    self.class.superclass.instance_method name
  end
end

p Foo.new.method(:bar).source_location.last                           # => 13
p Foo.new.class.superclass.instance_method(:bar).source_location.last # => 2
p Foo.new.super_method(:bar).source_location.last                     # => 2
~~~



----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46450

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62295] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (11 preceding siblings ...)
  2014-05-02  8:47 ` [ruby-core:62285] " ryand-ruby
@ 2014-05-02 15:02 ` richard.schneeman
  2014-05-08 19:51 ` [ruby-core:62467] " josh.cheek
                   ` (11 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: richard.schneeman @ 2014-05-02 15:02 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Richard Schneeman.


Ryan, using superclass gets you really close, but doesn't handle extending object instances:

```
class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end

class Object
  def super_method name
    self.class.superclass.instance_method name
  end
end


module MixinFoo
  def bar
    puts "MixinFoo"
  end
end

foo = Foo.new
foo.extend(MixinFoo)
foo.bar # => "MixinFoo"

puts foo.super_method(:bar)
#<UnboundMethod: BigFoo#bar> # wrong return
```

This is why my original code snippet uses ancestors rather than just superclass. We should see `MixinFoo` rather than `BigFoo`.

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46459

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62467] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (12 preceding siblings ...)
  2014-05-02 15:02 ` [ruby-core:62295] " richard.schneeman
@ 2014-05-08 19:51 ` josh.cheek
  2014-05-30  7:41 ` [ruby-core:62855] " nobu
                   ` (10 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: josh.cheek @ 2014-05-08 19:51 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Josh Cheek.


I've only ever needed to do this in codebases like Rails, where there's an insane amount of inheritance. However, Rails also relies heavily on method_missing, which `super_method` would completely miss.

Anyway, I'd like this method to exist also.

Here's my crack at implementing it:

```
class Method
  def super_method
    receiver.singleton_class
            .ancestors
            .drop_while { |ancestor| ancestor != owner }
            .drop(1)
            .first
            .instance_method(name)
            .bind(receiver)
  rescue NameError
    raise NameError, "No super method `#{name}' for class `#{owner}'"
  end
end


class BigFoo
  def bar
  end
end

class Foo < Class.new(Class.new(Class.new(BigFoo)))
  def bar
  end
end

module MixinFoo 
  def bar
  end
end

Foo.new               # => #<Foo:0x007fc123148728>
   .extend(MixinFoo)  # => #<Foo:0x007fc123148728>
   .method(:bar)      # => #<Method: Foo(MixinFoo)#bar>
   .super_method      # => #<Method: Foo(Foo)#bar>
   .super_method      # => #<Method: Foo(BigFoo)#bar>
```

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46623

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:62855] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (13 preceding siblings ...)
  2014-05-08 19:51 ` [ruby-core:62467] " josh.cheek
@ 2014-05-30  7:41 ` nobu
  2014-06-10  8:32 ` [ruby-core:63052] " ko1
                   ` (9 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: nobu @ 2014-05-30  7:41 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Nobuyoshi Nakada.

Related to Feature #7836: Need a way to get Method and UnboundMethod objects to methods overridden by prepended modules added

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-46974

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:63052] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (14 preceding siblings ...)
  2014-05-30  7:41 ` [ruby-core:62855] " nobu
@ 2014-06-10  8:32 ` ko1
  2014-06-10  8:51 ` [ruby-core:63055] [ruby-trunk - Feature #9781] [Feedback] " matz
                   ` (8 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ko1 @ 2014-06-10  8:32 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Koichi Sasada.

Assignee set to Yukihiro Matsumoto
Target version set to current: 2.2.0

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-47132

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:63055] [ruby-trunk - Feature #9781] [Feedback] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (15 preceding siblings ...)
  2014-06-10  8:32 ` [ruby-core:63052] " ko1
@ 2014-06-10  8:51 ` matz
  2014-06-10 18:07 ` [ruby-core:63068] [ruby-trunk - Feature #9781] " richard.schneeman
                   ` (7 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: matz @ 2014-06-10  8:51 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Yukihiro Matsumoto.

Status changed from Open to Feedback

Having something like Method/UnboundMethod#super_method for debugging purpose is OK, but

* Is super_method is the right name?  It sounds little bit weird for me.
* I don't like Object#super_method.

Matz.


----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-47134

* Author: Richard Schneeman
* Status: Feedback
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:63068] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (16 preceding siblings ...)
  2014-06-10  8:51 ` [ruby-core:63055] [ruby-trunk - Feature #9781] [Feedback] " matz
@ 2014-06-10 18:07 ` richard.schneeman
  2014-06-11 11:43 ` [ruby-core:63104] " ruby-core
                   ` (6 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: richard.schneeman @ 2014-06-10 18:07 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Richard Schneeman.


I am also not in love with the naming. I would have preferred `Method#super` but we don't want to overwrite `super` or confuse functionality here. Maybe something along the lines of `get_super`. Does anyone have a better naming suggestion?

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-47148

* Author: Richard Schneeman
* Status: Feedback
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:63104] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (17 preceding siblings ...)
  2014-06-10 18:07 ` [ruby-core:63068] [ruby-trunk - Feature #9781] " richard.schneeman
@ 2014-06-11 11:43 ` ruby-core
  2014-07-26  8:23 ` [ruby-core:64044] " matz
                   ` (5 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ruby-core @ 2014-06-11 11:43 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Marc-Andre Lafortune.


I also favor `super` (as I wrote before). It wouldn't overwrite the `super` keyword in most cases, and if it does (say from an instance method of Method) then there is still `self.super`.

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-47169

* Author: Richard Schneeman
* Status: Feedback
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:64044] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (18 preceding siblings ...)
  2014-06-11 11:43 ` [ruby-core:63104] " ruby-core
@ 2014-07-26  8:23 ` matz
  2014-07-26  8:24 ` [ruby-core:64045] [ruby-trunk - Feature #9781] [Open] " matz
                   ` (4 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: matz @ 2014-07-26  8:23 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Yukihiro Matsumoto.


OK, accepted.

The name should be 'super_method', since 'super' make me feel invocation of a mehtod in super class.
The 'super_method' should return nil when there's no method in superclasses.

Matz.


----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-48056

* Author: Richard Schneeman
* Status: Feedback
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:64045] [ruby-trunk - Feature #9781] [Open] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (19 preceding siblings ...)
  2014-07-26  8:23 ` [ruby-core:64044] " matz
@ 2014-07-26  8:24 ` matz
  2014-07-26 16:22 ` [ruby-core:64057] [ruby-trunk - Feature #9781] [Closed] " nobu
                   ` (3 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: matz @ 2014-07-26  8:24 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Yukihiro Matsumoto.

Status changed from Feedback to Open
Assignee changed from Yukihiro Matsumoto to okkez _

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-48057

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: okkez _
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:64057] [ruby-trunk - Feature #9781] [Closed] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (20 preceding siblings ...)
  2014-07-26  8:24 ` [ruby-core:64045] [ruby-trunk - Feature #9781] [Open] " matz
@ 2014-07-26 16:22 ` nobu
  2014-08-02 11:04 ` [ruby-core:64161] [ruby-trunk - Feature #9781] " aleksandrs
                   ` (2 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: nobu @ 2014-07-26 16:22 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Nobuyoshi Nakada.

Status changed from Open to Closed
% Done changed from 0 to 100

Applied in changeset r46964.

----------
proc.c: method_super_method

* proc.c (method_super_method): new method Method#super_method,
  which returns a method object of the method to be called by
  `super` in the receiver method object.
  [ruby-core:62202] [Feature #9781]

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-48067

* Author: Richard Schneeman
* Status: Closed
* Priority: Normal
* Assignee: okkez _
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:64161] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (21 preceding siblings ...)
  2014-07-26 16:22 ` [ruby-core:64057] [ruby-trunk - Feature #9781] [Closed] " nobu
@ 2014-08-02 11:04 ` aleksandrs
  2014-09-08 13:51 ` [ruby-core:64865] " nobu
  2015-02-10 13:38 ` [ruby-core:68079] [Ruby trunk " eregontp
  24 siblings, 0 replies; 26+ messages in thread
From: aleksandrs @ 2014-08-02 11:04 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Aleksandrs Ļedovskis.


Yukihiro Matsumoto wrote:
> OK, accepted.
> 
> The name should be 'super_method', since 'super' make me feel invocation of a mehtod in super class.
> The 'super_method' should return nil when there's no method in superclasses.
> 
> Matz.

Wouldn't it be more consistent to name this method `supermethod`, i.e. without "_" in the middle?
Thus it would be logical extension to `super<something>` family, which now consists of `Class#superclass`


----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-48164

* Author: Richard Schneeman
* Status: Closed
* Priority: Normal
* Assignee: okkez _
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:64865] [ruby-trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (22 preceding siblings ...)
  2014-08-02 11:04 ` [ruby-core:64161] [ruby-trunk - Feature #9781] " aleksandrs
@ 2014-09-08 13:51 ` nobu
  2015-02-10 13:38 ` [ruby-core:68079] [Ruby trunk " eregontp
  24 siblings, 0 replies; 26+ messages in thread
From: nobu @ 2014-09-08 13:51 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Nobuyoshi Nakada.

Duplicated by Feature #10216: Add methods to Method and UnboundMethod classess to retrieve method instance for super added

----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-48729

* Author: Richard Schneeman
* Status: Closed
* Priority: Normal
* Assignee: okkez _
* Category: core
* Target version: current: 2.2.0
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [ruby-core:68079] [Ruby trunk - Feature #9781] Feature Proposal: Method#super_method
       [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
                   ` (23 preceding siblings ...)
  2014-09-08 13:51 ` [ruby-core:64865] " nobu
@ 2015-02-10 13:38 ` eregontp
  24 siblings, 0 replies; 26+ messages in thread
From: eregontp @ 2015-02-10 13:38 UTC (permalink / raw
  To: ruby-core

Issue #9781 has been updated by Benoit Daloze.


Marc-Andre Lafortune wrote:
> I must be tired.
> 
> Nobu: Sorry, I was confused, there's no problem with `UnboundMethod#super_method` because we retain which class this method was accessed from.
> 
> Ryan: That's actually a good example, there is no api to get the "original owner" of an unbound method, so in general it's not possible to implement `super_method` in Ruby. E.g. from `Hash.instance_method(:map)`, I don't know of a way to get back `Hash` in pure Ruby, and thus no way to go through Hash's ancestry chain.

Actually there is a caveat with an UnboundMethod created with Module#instance_method, from a module (and not a class), as it has no idea what is the actual super method (as that can change in different ancestry chains).
Instead it will just return a method if there is a module "M" included in the former module with a corresponding method, and that method might be somewhere in the ancestry of an object including M or not (if "M" was included after).


----------------------------------------
Feature #9781: Feature Proposal: Method#super_method
https://bugs.ruby-lang.org/issues/9781#change-51463

* Author: Richard Schneeman
* Status: Closed
* Priority: Normal
* Assignee: okkez _
----------------------------------------

When `super` is called in a method the Ruby VM knows how to find the next ancestor that has that method and call it. It is difficult to do this manually, so I propose we expose this information in Method#super_location.

Ruby Method class (http://www.ruby-doc.org/core-2.1.1/Method.html) is returned by calling Object.method and passing in a method name (http://www.ruby-doc.org/core-2.1.1/Object.html#method-i-method). This is useful for debugging:

```ruby
# /tmp/code.rb
class Foo
  def bar
  end
end

puts Foo.new.method(:bar).source_location
# => ["/tmp/code.rb", 3]
```

The Object#method allows a ruby developer to easily track the source location of the method and makes debugging very easy. However if the code is being invoked by a call to `super` it is difficult to track down:

```ruby
# /tmp/code.rb

class BigFoo
  def bar
  end
end

class Foo < BigFoo
  def bar
    super
  end
end
```

In this code sample it is easy to find the method definition inside of Foo but it is very difficult in large projects to find what code exactly `super` is calling. This simple example is easy, but it can be hard when there are many ancestors. Currently if I wanted to find this we can inspect ancestors

```ruby
Foo.ancestors[1..-1].map do |ancestor|
  next unless ancestor.method_defined?(:bar)
  ancestor.instance_method(:bar)
end.compact.first.source_location
```

To make this process simpler I am proposing a method on the Method class that would return the result of `super`


It could be called like this:

```ruby
Foo.new.method(:bar).super_method
```

I believe adding Method#super_method, or exposing this same information somewhere else, could greatly help developers to debug large systems easily.




-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2015-02-10 13:37 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <redmine.issue-9781.20140428220712@ruby-lang.org>
2014-04-28 22:07 ` [ruby-core:62202] [ruby-trunk - Feature #9781] [Open] Feature Proposal: Method#super_method richard.schneeman
2014-04-28 22:23 ` [ruby-core:62203] [ruby-trunk - Feature #9781] " tenderlove
2014-04-29  1:59 ` [ruby-core:62206] " nobu
2014-04-29  4:24 ` [ruby-core:62209] " charliesome
2014-04-30  7:13 ` [ruby-core:62243] " ko1
2014-04-30 16:35 ` [ruby-core:62253] " nobu
2014-04-30 17:04   ` [ruby-core:62254] " SASADA Koichi
2014-04-30 17:11 ` [ruby-core:62255] " ko1
2014-05-01 23:10 ` [ruby-core:62272] " ryand-ruby
2014-05-02  2:43 ` [ruby-core:62275] " ruby-core
2014-05-02  3:03 ` [ruby-core:62276] " ruby-core
2014-05-02  3:14 ` [ruby-core:62277] " ruby-core
2014-05-02  8:47 ` [ruby-core:62285] " ryand-ruby
2014-05-02 15:02 ` [ruby-core:62295] " richard.schneeman
2014-05-08 19:51 ` [ruby-core:62467] " josh.cheek
2014-05-30  7:41 ` [ruby-core:62855] " nobu
2014-06-10  8:32 ` [ruby-core:63052] " ko1
2014-06-10  8:51 ` [ruby-core:63055] [ruby-trunk - Feature #9781] [Feedback] " matz
2014-06-10 18:07 ` [ruby-core:63068] [ruby-trunk - Feature #9781] " richard.schneeman
2014-06-11 11:43 ` [ruby-core:63104] " ruby-core
2014-07-26  8:23 ` [ruby-core:64044] " matz
2014-07-26  8:24 ` [ruby-core:64045] [ruby-trunk - Feature #9781] [Open] " matz
2014-07-26 16:22 ` [ruby-core:64057] [ruby-trunk - Feature #9781] [Closed] " nobu
2014-08-02 11:04 ` [ruby-core:64161] [ruby-trunk - Feature #9781] " aleksandrs
2014-09-08 13:51 ` [ruby-core:64865] " nobu
2015-02-10 13:38 ` [ruby-core:68079] [Ruby trunk " eregontp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).