In Ruby, how do you write method_missing for a settings object that answers any config key as a method, and why must it call super?

## The goal A settings object loaded from a YAML or JSON file holds keys such as `port`, `host` and `timeout`. Callers would rather write `settings.port` than `settings["port"]`. The keys are not known when the class is written, so there is no method to define in advance; `method_missing` can answer them. ## A correct implementation ```ruby class Settings def initialize(values) = @values = values.transform_keys(&:to_s) def method_missing(name, *args, &block) key = name.to_s if key.end_with?("=") && args.size == 1 && @values.key?(key.chomp("=")) @values[key.chomp("=")] = args.first elsif @values.key?(key) && args.empty? @values[key] else super end end def respond_to_missing?(name, include_private = false) key = name.to_s.chomp("=") @values.key?(key) || super end end settings = Settings.new(port: 8080, host: "db") settings.port # => 8080 settings.port = 9090 settings.prot # NoMethodError: undefined method 'prot' for an instance of Settings ``` The shape to remember: 1. **Recognise** only names you really handle, and check the arguments too: a reader takes none, a writer exactly one and only for an existing key. 2. **Answer** those names. 3. **Call `super`** for everything else, with no arguments, so the original name, arguments and block go to the default handler. 4. **Pair it with `respond_to_missing?`**, so `respond_to?` and `method` agree with what `method_missing` answers. ## Why super is not optional Without `super`, the last branch would return `nil` or some other value for every unknown name. A typo such as `settings.prot` would then quietly return `nil`, and the failure would surface later and far away, as a `nil` port passed to a socket. Calling `super`: - raises the normal `NoMethodError` with the real name and the caller's line in the backtrace; - keeps any ancestor's `method_missing` working, for example one added by a module included in `Settings`; - preserves the **error class**: a bare identifier inside the class still gives `NameError`, because the default handler knows how the original call was written. Bare `super` passes along exactly what `method_missing` received. If you narrow the arguments by hand, use `super(name, *args, &block)` rather than dropping some. ## Traps specific to method_missing | Trap | What happens | Fix | |---|---|---| | Calling an undefined method inside `method_missing` | it calls `method_missing` again, forever, until `SystemStackError` ("stack level too deep") | use only defined methods and instance variables inside it | | A key named like a public method (`display`, `freeze`, `hash`) | the real method runs; `method_missing` is never reached | reject such keys at load time, or read with `[]` | | A key named like a private `Kernel` method (`format`, `system`) | reaches `method_missing`, because a private method called with a receiver counts as missing | same: validate keys or use `[]` | | Defining `method_missing` on `Object` itself | Ruby warns "redefining Object#method_missing may cause infinite loop" and every object is affected | define it in the one class that needs it | ## Testing it A small set of tests pins the behaviour down: - a known key returns its value, and a writer stores a new one; - an unknown name raises `NoMethodError` with that name (`error.name == :prot`); - `respond_to?` agrees with `method_missing` for a known key, a writer and an unknown name; - a reader called with an argument is refused, so `settings.port(1)` does not silently ignore it. ## When not to use it For a fixed set of fields, `Struct` or `Data.define` gives real methods, real `respond_to?` answers and better speed. `method_missing` is for names that truly are open-ended, like keys in a loaded file. Even then, a plain `fetch("port")` API is simpler; ghost methods are a convenience that must be earned. ## What an interviewer is listening for The expected answer shows a `method_missing` that matches only the names it handles, returns their values, and calls `super` otherwise, explaining that skipping `super` turns typos into silent `nil`s. Strong answers mention `respond_to_missing?`, argument checks for readers and writers, the recursion trap and keys that collide with real methods.