I use IRB to explore. Very often I type a.methods.sort, to see what an
object can do. The problem is, you’re hit with 100 methods from Object
(or the superclass).
I’ve experimented with:
a.methods - a.class.superclass.methods
which works well for simple things
but it doesn’t seem to handle cases when there are a lot of included
modules. Any ideas on how to see the methods defined in a.class only,
and not in any superclass or included module?
[email protected] wrote:
and not in any superclass or included module?
methods has a switch:
object.methods(false)
and
klass.instance_methods(false)
Also, keep in mind the differences between:
methods
public_methods
private_methods
protected_methods
instance_methods
public_instance_methods
private_instance_methods
protected_instance_methods
I’ve made a fool of myself more than once thinking the first combined
the later three – it does not. methods is alias of public_methods and
likewise for the instance version.
T.
[email protected] schrieb:
protected_instance_methods
I’ve made a fool of myself more than once thinking the first combined
the later three – it does not.
Me too.
methods is alias of public_methods and
likewise for the instance version.
That’s not quite correct. Kernel#methods and Module#instance_methods
return both public and protected methods:
class C
public; def pub; end
protected; def prot; end
private; def priv; end
end
p C.instance_methods(false) # => [“prot”, “pub”]
Regards,
Pit
On 19/07/06, [email protected] [email protected] wrote:
and not in any superclass or included module?
This isn’t exactly the answer to your question, but I’ve defined a
couple of methods in my .irbrc that I’ve found really useful. The
first is methods aliased to methods.sort (because that’s always what I
want in irb, and the overhead doesn’t matter there). The second is
distinct_methods, which is all the methods that aren’t inherited from
Object:
class Object
alias_method :methods, :methods
def methods
return methods.sort
end
def distinct_methods
(methods - Object.methods).sort
end
end
The latter generally produces a manageable list, so I haven’t found
the need to exclude methods from included modules or superclasses.
Paul.