Method lookup chain in Ruby - Time & Space Complexity
When Ruby runs a method, it looks through a chain of places to find it.
We want to see how long this search takes as the chain grows.
Analyze the time complexity of the following code snippet.
module M1
def greet
"Hello from M1"
end
end
class C
include M1
def greet
"Hello from C"
end
end
obj = C.new
obj.greet
This code calls greet on an object, Ruby looks up the method through the class and included modules.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Ruby checks each place in the method lookup chain one by one.
- How many times: It checks until it finds the method or reaches the end of the chain.
As the number of modules and classes in the lookup chain grows, Ruby checks more places.
| Input Size (n) | Approx. Operations |
|---|---|
| 3 | 3 checks |
| 10 | 10 checks |
| 100 | 100 checks |
Pattern observation: The number of checks grows directly with the chain length.
Time Complexity: O(n)
This means the time to find a method grows in a straight line as the chain gets longer.
[X] Wrong: "Ruby finds methods instantly no matter how many modules or classes are included."
[OK] Correct: Ruby checks each place one by one, so more places mean more time.
Understanding method lookup helps you explain how Ruby finds methods and why code organization matters.
"What if Ruby used a cache to remember where methods are found? How would that change the time complexity?"
Practice
What does the method lookup chain in Ruby represent?
Solution
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.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.Final Answer:
The order Ruby searches to find a method to execute -> Option BQuick Check:
Method lookup chain = method search order [OK]
- Confusing method lookup with variable list
- Thinking it shows method call sequence
- Mixing lookup with code compilation order
Which Ruby code correctly shows the method owner for to_s called on a string?
"hello".method(:to_s).owner
Solution
Step 1: Recall where
Theto_sis defined for Stringto_smethod for String objects is actually defined in the Kernel module, which is included in Object, and thus available to String.Step 2: Check method owner for
Usingto_son a String object"hello".method(:to_s).ownerreturns Kernel because String does not overrideto_s.Final Answer:
Kernel -> Option DQuick Check:
to_s owner for String = Kernel [OK]
- Assuming method is owned by String
- Confusing Object and BasicObject
- Forgetting Kernel defines to_s
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
Solution
Step 1: Understand method lookup order with include and override
Class C includes module M1, but also defines its owngreetmethod, which overrides the module's method.Step 2: Determine which greet method is called
Ruby looks first in C, findsgreetthere, so it calls "Hello from C".Final Answer:
Hello from C -> Option AQuick Check:
Method override in class wins over included module [OK]
- Thinking included module method runs first
- Expecting NoMethodError due to confusion
- Assuming Object's method is called
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
Solution
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.Step 2: Determine which hello method runs
Callinghelloon obj calls M's method, outputting "Hi from M".Final Answer:
No error, output is "Hi from M" -> Option AQuick Check:
Prepend puts module before class in lookup [OK]
- Expecting class method to run instead
- Thinking prepend causes syntax error
- Confusing prepend with include
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?
Solution
Step 1: Analyze method lookup order with prepend and include
Prepend M2 places it before Derived, then Derived, then included M1, then Base.Step 2: Identify which info method is called
Since M2 is first in lookup, itsinfomethod runs, printing "M2".Final Answer:
M2, because prepend puts M2 before Derived in lookup -> Option CQuick Check:
Prepend > class > include > superclass [OK]
- Thinking include module method runs first
- Assuming class method overrides prepend module
- Ignoring method lookup chain order
Ready to prove it?
Pass the test and this pattern moves unknown
