Feature #614
closedinstance_method(ancestor)
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
Updated by ko1 (Koichi Sasada) almost 16 years ago
- Assignee set to matz (Yukihiro Matsumoto)
Updated by znz (Kazuhiro NISHIYAMA) over 14 years ago
- Target version set to 2.0.0
Updated by shyouhei (Shyouhei Urabe) about 14 years ago
- Status changed from Open to Assigned
Updated by mame (Yusuke Endoh) almost 13 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 [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 mame@tsg.ne.jp
Updated by trans (Thomas Sawyer) almost 13 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) almost 13 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
Updated by ko1 (Koichi Sasada) about 12 years ago
- Target version changed from 2.0.0 to 2.6
Discussion was stopped.
Updated by matz (Yukihiro Matsumoto) about 7 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
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.