In Dart, why does calling an extension method on a `dynamic` variable fail, and what does static resolution mean for overriding?

## Two kinds of member lookup Dart has two ways to decide which code a call like `x.shout()` runs: - **Instance members** use **virtual (dynamic) dispatch**: the object's runtime class decides, so a subclass override wins even when `x` is typed as the superclass. - **Extension members** use **static resolution**: the compiler looks at the **static type** of `x`, finds an applicable extension, and turns the call into what is effectively a static function call with `x` as an argument. dart.dev puts it directly: extension methods are resolved against the static type of the receiver, and because of that they are as fast as calling a static function. ## Why `dynamic` breaks it ```dart import 'string_apis.dart'; // extension NumberParsing on String { int parseInt() ... } dynamic d = '2'; print(d.parseInt()); // Runtime exception: NoSuchMethodError var v = '2'; // inferred as String print(v.parseInt()); // 2 ``` The static type of `d` is `dynamic`. The compiler cannot match an `on String` extension against `dynamic`, so it compiles a dynamic call. At runtime the `String` object has no instance member named `parseInt`, and the call throws. Nothing is reported at compile time, which is what makes this a classic interview question. The fix is to give the receiver a static type: declare it `String`, cast it (`(d as String).parseInt()`), or apply the extension explicitly (`NumberParsing(d).parseInt()`, which also type-checks the argument). Common places a receiver silently becomes `dynamic`: 1. Values pulled out of decoded JSON (`jsonDecode` returns `dynamic`), such as `json['name'].toTitleCase()`. 2. Untyped `Map` or `List` literals in older code. 3. Parameters or variables written without a type where inference cannot help. ## What static resolution means for overriding Because the choice is made at compile time from the static type, three consequences follow. **The instance member always wins.** If the static type already declares a member with that name, the extension is not applicable, so the extension member is simply never chosen: ```dart extension Trimmer on String { String trim() => 'extension'; // legal, but never used by 'x'.trim() } ``` **Static type, not runtime type, picks the extension:** ```dart extension ShoutObject on Object { String shout() => 'object'; } extension ShoutString on String { String shout() => 'string'; } void main() { Object o = 'hi'; print(o.shout()); // object (static type Object) print('hi'.shout()); // string (String is the more specific on type) } ``` Both extensions apply to a `String` receiver; the one whose on type is **more specific** (`String` is a subtype of `Object`) wins. For `o`, only `ShoutObject` applies to the static type `Object`, so the runtime string makes no difference. **Extensions cannot be overridden or override.** A subclass cannot override an extension member, and an extension cannot replace a class's method for existing callers. If you need runtime polymorphism, you need an instance member (in a class or a mixin). ## Comparison | Aspect | Instance member | Extension member | |---|---|---| | Chosen by | runtime type of the object | static type of the expression | | Works on `dynamic` receiver | yes (checked at runtime) | no: `NoSuchMethodError` at runtime | | Can be overridden in a subclass | yes | no | | Same name as an instance member | — | instance member wins | | Cost of the call | virtual call | like a static function call | ## Interview framing Say "extension calls are syntactic sugar for static function calls chosen by the static type", then derive the three consequences: `dynamic` fails, the real member wins, and upcasting changes which extension runs. Mention that decoded JSON is where Flutter code most often hits the `dynamic` trap.