In Ruby, how can a `logged` class-level call use method_added to wrap the next method defined, and why can a naive version raise SystemStackError?

## The pattern: decorate the next method Some languages have syntax for method decorators. Ruby builds the same thing from a hook. The user writes: ```ruby class Report extend Logged logged def render = :ok end ``` `logged` is a class-level method (supplied by the extended module). It cannot see the next method yet, because that `def` has not run. So it sets a flag, and the class's **`method_added`** hook does the wrapping when the next definition arrives. ## Timing of method_added - Ruby calls `method_added(name)` on the class **after** the method is stored, so `instance_method(name)` inside the hook returns the new method. - It fires for every instance-method definition in that class: `def`, `define_method`, `attr_*`, `alias_method`. - It does **not** fire for `def self.x`; singleton methods go through `singleton_method_added`. - It runs on every definition, so the hook itself must be cheap and must ignore names it does not care about. ## The naive version and its recursion ```ruby module Logged def logged @log_next = true end def method_added(name) super return unless @log_next original = instance_method(name) define_method(name) { |*args| puts "-> #{name}"; original.bind(self).call(*args) } @log_next = false # too late end end ``` What happens when `def render` runs: 1. `method_added(:render)` sees the flag and captures the original `render`. 2. `define_method(:render)` stores the wrapper in `Report` — another definition. 3. Ruby calls `method_added(:render)` again. The flag is still true, so it captures the wrapper and defines another wrapper. 4. Step 3 repeats until the stack overflows: `SystemStackError: stack level too deep`. ## Two fixes | Fix | How | Why it works | |---|---|---| | Clear the flag first | set `@log_next = false` before `define_method` | the nested `method_added` call returns immediately | | Prepend a wrapper module | `prepend(Module.new { define_method(name) { \|*a\| super(*a) } })` | the definition happens in the anonymous module, so the class's `method_added` is not called; `super` reaches the original | The prepend version has further advantages: the original method stays untouched in the class, several decorators stack in the order they were prepended, and the wrapper module appears in `Report.ancestors`. ## Where the flag lives Both `logged` and `method_added` run with `self` set to the class (`Report`), because the module was added with `extend`. So `@log_next` is an instance variable of the class object itself: - each class that extends `Logged` has its own flag, so decorating in one class cannot leak into another; - a subclass starts with no flag set, even if its parent's flag was left on by mistake; - the flag must be reset in every path, including when the hook decides not to wrap, or the next unrelated method gets decorated. ## Related hooks - **`method_removed`** and **`method_undefined`** keep a registry of decorated methods accurate when methods are later removed or undefined. - **`singleton_method_added`** is the hook to use if the decorator should also apply to `def self.x` methods; note that defining that hook with `def self.singleton_method_added` reports its own name immediately. ## Production checklist 1. Call `super` in every hook; another library may be using the same hook on the same class. 2. Reset the flag before any definition the hook performs. 3. Keep the hook fast: it runs for every method the class defines, including generated accessors. 4. Test that decorating two consecutive methods wraps only the one after `logged`. ## Why interviewers ask This is a senior question about hook timing: the candidate should know that `method_added` fires after the definition, that the hook's own definitions trigger it, and how to break the cycle.