Method lookup chain in Ruby - Step-by-Step Execution

Concept Flow - Method lookup chain

Call method on object

↓

Check object's class for method

↓

Check included modules in order

↓

Method found in module?

↓

Execute method

↓

Done

↓

Done

↓

Check superclass

↓

Repeat check up the chain

Yes↓

Execute method

↓

Done

When you call a method on an object, Ruby looks for it first in the object's class, then in included modules in order, then up the superclass chain until it finds the method or ends.

Execution Sample

Ruby

module M
  def greet; "Hello from M"; end
end

class A
  include M
  def greet; "Hello from A"; end
end

class B < A; end

puts B.new.greet

This code calls greet on an instance of B, which looks up the method through B, A, and module M.

Execution Table

Step	Lookup Location	Method Found?	Action	Output
1	B (class)	No	Check superclass
2	A (superclass of B)	Yes	Use A#greet method	Hello from A
3	End		Method executed, stop lookup	Hello from A

💡 Method found in superclass A, so lookup stops and method is executed.

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
object	B instance	B instance	B instance	B instance
method_location	unknown	B class (no)	A class (yes)	A class

Key Moments - 2 Insights

Why does Ruby check the superclass A before the included module M in this example?

Because the module M is included in class A, Ruby first checks B, then A, then modules included in A. Since A defines greet, it stops there (see execution_table step 2).

What happens if the method is not found in the class or any included modules?

Ruby continues looking up the superclass chain until it finds the method or reaches BasicObject. If not found, it raises a NoMethodError (not shown in this example).

Visual Quiz - 3 Questions

Look at the execution table, at which step is the method greet found?

A Step 2

B Step 1

C Step 3

D Method not found

💡 Hint

Check the 'Method Found?' column in execution_table rows.

If class A did not define greet, where would Ruby look next?

A In class B again

B In superclass of A

C In modules included in A

D Stop and raise error

💡 Hint

Look at the concept_flow showing included modules are checked after class.

According to variable_tracker, what is the method_location after step 2?

A B class

B A class

C Module M

D Unknown

💡 Hint

See variable_tracker row for method_location after step 2.

Concept Snapshot

Method lookup chain in Ruby:
- Call method on object
- Check object's class
- Check included modules in order
- Check superclass chain
- Execute first found method
- If none found, raise NoMethodError

Full Transcript

When you call a method on an object in Ruby, the language looks for the method in a specific order called the method lookup chain. First, it checks the object's own class. If the method is not there, it looks in any modules included in that class, in the order they were included. If still not found, Ruby checks the superclass of the class, repeating the same process. This continues up the chain until the method is found or Ruby reaches the top class. If the method is found, Ruby executes it and stops looking further. If not found anywhere, Ruby raises an error. In the example, calling greet on an instance of class B causes Ruby to check B, then A, where greet is found and executed.

Practice

1.

What does the method lookup chain in Ruby represent?

easy

A. The list of all variables in a class

B. The order Ruby searches to find a method to execute

C. The sequence of method calls inside a method

D. The order Ruby compiles the code

Solution

1. Step 1: Understand method lookup chain meaning

   The method lookup chain is the path Ruby follows to find a method when called on an object.

2. Step 2: Compare options with definition

   Only The order Ruby searches to find a method to execute correctly describes this as the order Ruby searches for a method to execute.

3. Final Answer:

   The order Ruby searches to find a method to execute -> Option B

4. Quick Check:

   Method lookup chain = method search order [OK]

Hint: Think 'where Ruby looks for methods' [OK]

Common Mistakes:

• Confusing method lookup with variable list
• Thinking it shows method call sequence
• Mixing lookup with code compilation order

2.

Which Ruby code correctly shows the method owner for to_s called on a string?

"hello".method(:to_s).owner

easy

A. String

B. Object

C. BasicObject

D. Kernel

Solution

1. Step 1: Recall where to_s is defined for String

   The to_s method for String objects is actually defined in the Kernel module, which is included in Object, and thus available to String.

2. Step 2: Check method owner for to_s on a String object

   Using "hello".method(:to_s).owner returns Kernel because String does not override to_s.

3. Final Answer:

   Kernel -> Option D

4. Quick Check:

   to_s owner for String = Kernel [OK]

Hint: String inherits to_s from Kernel [OK]

Common Mistakes:

• Assuming method is owned by String
• Confusing Object and BasicObject
• Forgetting Kernel defines to_s

3.

Given this Ruby code, what is the output?

module M1
  def greet; "Hello from M1"; end
end

class C
  include M1
  def greet; "Hello from C"; end
end

obj = C.new
puts obj.greet

medium

A. Hello from C

B. Hello from M1

C. NoMethodError

D. Hello from Object

Solution

1. Step 1: Understand method lookup order with include and override

   Class C includes module M1, but also defines its own greet method, which overrides the module's method.

2. Step 2: Determine which greet method is called

   Ruby looks first in C, finds greet there, so it calls "Hello from C".

3. Final Answer:

   Hello from C -> Option A

4. Quick Check:

   Method override in class wins over included module [OK]

Hint: Class methods override included module methods [OK]

Common Mistakes:

• Thinking included module method runs first
• Expecting NoMethodError due to confusion
• Assuming Object's method is called

4.

What is the error in this Ruby code snippet?

module M
  def hello; "Hi from M"; end
end

class A
  prepend M
  def hello; "Hi from A"; end
end

obj = A.new
puts obj.hello

medium

A. No error, output is "Hi from M"

B. No error, output is "Hi from A"

C. SyntaxError due to prepend usage

D. NoMethodError for hello

Solution

1. Step 1: Understand prepend effect on method lookup

   Prepending module M places it before class A in the lookup chain, so M's methods override A's.

2. Step 2: Determine which hello method runs

   Calling hello on obj calls M's method, outputting "Hi from M".

3. Final Answer:

   No error, output is "Hi from M" -> Option A

4. Quick Check:

   Prepend puts module before class in lookup [OK]

Hint: Prepend modules override class methods [OK]

Common Mistakes:

• Expecting class method to run instead
• Thinking prepend causes syntax error
• Confusing prepend with include

5.

Consider this Ruby code:

module M1
  def info; "M1"; end
end

module M2
  def info; "M2"; end
end

class Base
  def info; "Base"; end
end

class Derived < Base
  include M1
  prepend M2
end

obj = Derived.new
puts obj.info

What will be printed and why?

hard

A. M1, because include puts M1 before Base

B. Base, because class method overrides modules

C. M2, because prepend puts M2 before Derived in lookup

D. NoMethodError, info not found

Solution

1. Step 1: Analyze method lookup order with prepend and include

   Prepend M2 places it before Derived, then Derived, then included M1, then Base.

2. Step 2: Identify which info method is called

   Since M2 is first in lookup, its info method runs, printing "M2".

3. Final Answer:

   M2, because prepend puts M2 before Derived in lookup -> Option C

4. Quick Check:

   Prepend > class > include > superclass [OK]

Hint: Prepend modules come before class, include after [OK]

Common Mistakes:

• Thinking include module method runs first
• Assuming class method overrides prepend module
• Ignoring method lookup chain order