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:
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.
#4 [ruby-core:42392] Updated by mame (Yusuke Endoh) about 5 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 .
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 firstname.lastname@example.org
#5 [ruby-core:42398] Updated by trans (Thomas Sawyer) about 5 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 [ruby-core:42403] Updated by mame (Yusuke Endoh) about 5 years ago
- Status changed from Rejected to Assigned
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 email@example.com