Method Dispatching

Method Lookup Order

If an object receives a message, then Ruby looks for a receiver of the same name, in this order:

1. its singleton class
2. its class
3. its modules, in reverse order of inclusion
4. its superclass
5. its superclass' modules

... and so on

This chain ends with Object, which mixes in Kernel, and finally BasicObject (which has no mixins)

ancestors

Check out the ancestors class method

>> String.ancestors
=> [String, Comparable, Object, Kernel, BasicObject]

Schematically:

class BasicObject
end
class Object < BasicObject
  include Kernel
end
class String < Object
  include Comparable
end

super (cont.)

• super with some arguments passes those arguments
• super with no arguments passes the same arguments that were originally passed to this method
• super() with an empty argument list calls the parent method with no arguments
  • needed to resolve the ambiguity of the bareword super call

method_missing

If method dispatch fails, then it starts all over again!

Only this time it's looking for a method named method_missing

Useful for "builder pattern" objects

Ref. WGR Section 4.3. The method_missing method

class Thing
  def method_missing method_name, *args
    puts method_name.to_s.reverse
    args.reverse
  end
end

t = Thing.new
t.whatever "hee", "haw"

revetahw
=> ["haw", "hee"]

method_missing + super

From inside method_missing, super looks up the chain for another method_missing method

Allows chaining/overriding of method_missing calls, or fallback to NoMethodError

    def x.method_missing(name)
      if (name == :hee)
        puts "HAW!"
      else
        super
      end
    end

 Previous Lesson Next Lesson 

Outline