Feature #614

instance_method(ancestor)

Added by Thomas Sawyer over 5 years ago. Updated over 1 year ago.

[ruby-core:19120]
Status:Assigned
Priority:Normal
Assignee:Yukihiro Matsumoto
Category:core
Target version:next minor

Description

=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

History

#1 Updated by Koichi Sasada over 5 years ago

  • Assignee set to Yukihiro Matsumoto

=begin

=end

#2 Updated by Kazuhiro NISHIYAMA about 4 years ago

  • Target version set to 2.0.0

=begin

=end

#3 Updated by Shyouhei Urabe over 3 years ago

  • Status changed from Open to Assigned

=begin

=end

#4 Updated by Yusuke Endoh about 2 years ago

  • Status changed from Assigned to Rejected

Hello,

I'm rejecting this feature ticket because no progress has been made
for a long time. See .

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 mame@tsg.ne.jp

#5 Updated by Thomas Sawyer about 2 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.

#6 Updated by Yusuke Endoh about 2 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 mame@tsg.ne.jp

#7 Updated by Koichi Sasada over 1 year ago

  • Target version changed from 2.0.0 to next minor

Discussion was stopped.

Also available in: Atom PDF