Calling Methods Dynamically

## The problem reflection solves here Ordinary Go dispatch is decided when you write the code: you name a method, the compiler resolves it, the linker wires it up. Sometimes the name only exists at run time — an operator types `drain` into an admin console, and a command bus has to find the handler that matches. `reflect` is the standard library's answer: it lets a program look at a value's type and methods as data, and invoke one chosen by a string. ## The three steps **1. Get a `reflect.Value`.** `reflect.ValueOf(x)` takes any value and returns a `reflect.Value` — a run-time handle on the value together with its dynamic type. **2. Look the method up.** `Value.MethodByName(name string) Value` searches the value's method set for a method with that name and returns a *method value*: a `reflect.Value` of func kind whose receiver is already bound. That binding matters — the func type it reports through `Type()` lists only the declared parameters, so you do **not** pass the receiver yourself. (The other route, `Type.Method(i)`, gives you a `Func` whose first parameter *is* the receiver; the two are easy to confuse.) If no such method exists, `MethodByName` does not return an error and does not panic. It returns the **zero** `reflect.Value`, for which `IsValid()` reports false. Calling `Call` on that zero value panics with `call of reflect.Value.Call on zero Value`, so a name arriving from a user is always checked first. Only **exported** methods are reachable. For a non-interface type, `reflect` deliberately reports only the exported method set, so `MethodByName("drain")` on a method named `drain` finds nothing — reflection does not breach package encapsulation. **3. Call it.** `Value.Call(in []Value) []Value` invokes the func. Each element of `in` must be *assignable* to the corresponding declared parameter type; the results come back as a slice in declaration order. To build an argument you wrap it: `reflect.ValueOf("node-7")`. To read a result you unwrap it: `out[0].Interface()` returns an `any`, which you type-assert. For a variadic method, `Call` collects the trailing arguments into the variadic slice for you; `CallSlice` is the variant that takes an already-built slice as the final argument. ## Getting an error result out A handler that returns `error` needs one extra piece of care. `out[1].Interface()` on a nil error yields a nil `any`, and a single-value type assertion on a nil interface **panics**. Use the comma-ok form: err, _ := out[1].Interface().(error) When the call succeeded, `err` is nil and `ok` is false, which is exactly what you want. `out[1].IsNil()` works too, because the result's kind is `Interface`. ## What is not checked Nothing about this call is verified by the compiler. The method name is a string, the arguments are a slice, and every mismatch — wrong count, wrong type, unexported name, nil receiver — shows up as a run-time panic or a silent miss. That is the trade you are making: you buy dispatch from data, and you pay with checks the compiler used to do for you. A dispatcher that takes operator input therefore validates the resolved method's signature before calling, and a panic escaping `Call` should not be allowed to take the process down. ## Which methods are visible `reflect.ValueOf(v)` exposes the method set of the value you handed it. Hand it a `T` and you see the methods declared on `T`; hand it a `*T` and you see those declared on `T` and on `*T`. A command bus therefore registers pointers to its handler structs, not copies of them. ## Cost A reflected call is far slower than a direct one — the lookup walks a name table, the arguments are boxed into `reflect.Value`s, and the call goes through the runtime rather than a direct branch. For an admin command that runs once a minute that is irrelevant; on a hot path it is not, and a plain `map[string]func(...)` registry is both faster and safer.