Feature #614



Added by trans (Thomas Sawyer) over 14 years ago. Updated over 5 years ago.

Target version:


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)

But it would be nice if we could simply use:


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.

Actions #1

Updated by ko1 (Koichi Sasada) over 14 years ago

  • Assignee set to matz (Yukihiro Matsumoto)
Actions #2

Updated by znz (Kazuhiro NISHIYAMA) about 13 years ago

  • Target version set to 2.0.0
Actions #3

Updated by shyouhei (Shyouhei Urabe) over 12 years ago

  • Status changed from Open to Assigned

Updated by mame (Yusuke Endoh) over 11 years ago

  • Status changed from Assigned to Rejected


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

Updated by trans (Thomas Sawyer) over 11 years ago

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.

Updated by mame (Yusuke Endoh) over 11 years ago

  • 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

Updated by ko1 (Koichi Sasada) over 10 years ago

  • Target version changed from 2.0.0 to 2.6

Discussion was stopped.

Updated by matz (Yukihiro Matsumoto) over 5 years ago

  • 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

module B

module C
  include A
  include B

module D
  include B
  include A

We need other use-cases to discuss further.



Also available in: Atom PDF