One property of the Ruby object model and object oriented programming in general is that a subclass of an object automatically inherits all of the methods of its superclass. Classes can further expand the number of methods available by mixing in a Module, or several.
Because of mixins and subclassing even a class that has declared just a few methods can actually have hundreds of methods on it. In Ruby, all classes subclass Object by default which declares a hefty 45 methods, guaranteeing you to have at least that many. Out of the box in 1.8.7, a Ruby String object has 176 instance methods. If you are programming on top of the Rails framework, ActiveSupport adds 98 methods bringing the total to 274!
On numerous occasions I have needed to see what methods are available on an object I am working with I will type the following in irb.
myobject.methods - Object.instance_methods
This prints out a large array of instance methods with the methods inherited from Object removed from the list. This is useful but what if the object I am working with mixed in several modules and I am left with a list of over a hundred methods? It would be great to view which Class or Module each method came from. Well, actually there's a gem for that.™
Looksee
Looksee is a new gem by George Ogata that examines the method lookup path of any object. To use it add require 'looksee/shortcuts' to your ~/.irbrc. This will add a lp ("lookup path") method to your irb environment. When passed an object lp prints out a colored display showing where each of an object's methods lives.
- public methods are show in green
- protected methods are show in yellow
- private methods are show in red
- overwritten methods are show in gray
Go ahead and install Looksee and play around with it for a moment. Run lp on a String in vanilla irb and then open script/console in a Rails project and do the same thing. It is quite eye-opening to see the additions that the Rails framework makes.
Awesome, this looks really useful. I am still trying to decide if I like having the lookup_path and dump_lookup_path methods show up though. Doesn't seem like there would be a time I'd ever need to look that up as they'd have to be there to use the lp method and get this formatted listing in the first place.
This looks a lot like method_lister, http://github.com/matthew/method_lister/tree/master, which was created some time before. I don't know how they compare but I do prefer method_lister's format i.e. latest ancestors last.
@cldwalker- Nice! I had not seen method_lister previously. I am a bit embarrassed since method_lister was written by a fellow pivot, Matthew O'Connor. I like how method_lister has some advanced features so I will have to play around with it.
This is pretty cool. Unfortunately, the output doesn't play well with utility_belt (at least on osx).
Thanks for the write up and comments!
@Hunter Gillane - I think it's good to reflect the current environment as accurately as possible. You could use the 'grep' method:
lp([]).grep /^to/. Alternatively, there is a "pure" mode: if you just require 'looksee', it won't pollute Object - everything is confined to the Looksee module. You'll need to doLooksee.lookup_pathinstead oflp, though. Feel free to suggest ideas on the github tracker.@cldwalker - I hadn't seen method_lister - thanks for pointing it out. The main difference is that looksee is a little more accurate. e.g., try listing methods of a derived class object. It turns out ruby's reflection API is not quite adequate for this task, so looksee uses a C extension to walk the internal ancestor chains and iterate through the method tables.
@John Trupiano - fixed in 0.0.2. :)