Feature #614: instance_method(ancestor)

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: 2.6

[trans (Thomas Sawyer)]

=begin
Currently Module#instance_methods takes a single argument, true or false, as to whether to include all ancestor's methods. However sometimes limiting the search at a particular ancestor is helpful. Currently this requires code along the lines of:

 meths = []
 FooClass.ancestors[0..FooClass.ancestors.index(FooAncestor)].each do |anc|
   meths = meths | anc.instance_methods(false)
 end

But it would be nice if we could simply use:

 instance_methods(FooAncestor)

This change is, practically-speaking, backward compatible, since 'true' can be the same as 'Kernel', encompassing the entire ancestry.

This change is applicable to the entire family of "methods" methods, including Kernel#methods.

This change also helps eliminate the widely disliked true|false arguments.

The particular use case that brought this to mind was trying to write a Module#conflict? method that lists the methods two modules or classes have in common, but excluding the methods that they share from a common ancestor.
=end

[ko1 (Koichi Sasada)]

• Assignee set to matz (Yukihiro Matsumoto)

[znz (Kazuhiro NISHIYAMA)]

• Target version set to 2.0.0

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned

[mame (Yusuke Endoh)]

• Status changed from Assigned to Rejected

Hello,

I'm rejecting this feature ticket because no progress has been made
for a long time. See [ruby-core:42391].

The following is just my personal comment.

The use case you mentioned (Module#conflict?) looks too specific.
Please let us know if you have a more general use case.

If you want just Module#conflict?, why don't you propose itself?
(but the use case of Module#conflict? is also uncertain)

--
Yusuke Endoh [e-mail]

[trans (Thomas Sawyer)]

This is a good feature idea. It was even assigned!

The use case is specific b/c it is a specific example of use. What other kind can there be? I don't propose #conflict? as feature b/c I think THAT is too specific when this more generally applicable feature can easily be used to do it.

This feature has other uses. In general this feature can be useful when there is a base class and one needs list of available methods up to that base class and not beyond. Perhaps you are delegating and only wish to delegate up to certain level.

It can be difficult to think of examples for anything when you are not in the thick of it. For instance, off the top of your head give a good use case for using #instance_methods as it is? Don't be too specific ;)

Anyway, I think this feature should not be rejected. I wish I had the know-how to do it myself, I would. But C turns my stomach in knots, which is why I code in Ruby :) Hmm... Too bad Ruby core has no bounty system.

[mame (Yusuke Endoh)]

• Status changed from Rejected to Assigned

Okay, reopened.

In fact, a use case is not necessarily needed.
Ultimately, what you need is an approval from matz.
But matz will require other use cases, I guess.

--
Yusuke Endoh [e-mail]

[ko1 (Koichi Sasada)]

• Target version changed from 2.0.0 to 2.6

Discussion was stopped.

[matz (Yukihiro Matsumoto)]

• Status changed from Assigned to Rejected

Even if we provide the proposed feature, we cannot implement Module#conflict?, because ancestor order is not common.

module A
end

module B
end

module C
  include A
  include B
end

module D
  include B
  include A
end

We need other use-cases to discuss further.

Matz.