In JavaScript, when a method body contains `super.greet()`, how does the engine decide which object `greet` is looked up on, and why does copying that method onto a different object not change the answer?

## Two different questions `super.x` has to answer A call like `super.greet()` involves two decisions: *where do I look the property up*, and *what is `this` when I call it*. JavaScript answers them from different sources, and every surprise in this area comes from confusing the two. - **Lookup** starts from the prototype of the method's `[[HomeObject]]`. - **Receiver** is the current `this`, unchanged. That split is deliberate. Using `this` for lookup would be the naive design, and it breaks immediately: a three-level hierarchy where the middle class calls `super.greet()` would find its own method again through `Object.getPrototypeOf(this)` and recurse forever. ## What `[[HomeObject]]` is When the engine evaluates a **concise method definition**, it stamps the resulting function with an internal slot recording the object the method was defined in. Concise means the shorthand form — `greet() {}`, `get x() {}`, `set x(v) {}`, `*gen() {}`, `async run() {}` — inside either a class body or an object literal. For an instance method of a class, the home object is `C.prototype`; for a static method it is the class `C` itself; for an object literal method it is the literal. A function *expression* assigned to a property gets no such slot: ```js const obj = { greet: function () { return super.greet(); } // SyntaxError }; ``` This is rejected at parse time rather than failing at call time, because the parser knows `super` cannot be resolved in that position. ## The consequence: `super` travels with the method Because the slot lives on the function object, it survives being moved: ```js const parent = { greet() { return 'parent'; } }; const child = Object.setPrototypeOf( { greet() { return 'child -> ' + super.greet(); } }, parent ); const other = Object.setPrototypeOf({}, { greet() { return 'other'; } }); other.greet = child.greet; child.greet(); // "child -> parent" other.greet(); // "child -> parent" <- not "child -> other" ``` `other.greet()` runs with `this === other`, so any `this.x` inside would read `other`'s state — but `super.greet` still resolves through `child`, the object the method was written in. `Object.assign(other, child)` behaves identically, because it copies the same function object. This matters for mixin helpers that copy methods between prototypes. Copying a method that uses `super` silently keeps pointing at the donor's parent, so the mixin appears to work until someone changes the donor's hierarchy. Mixins implemented as class factories — a function returning `class extends Base {}` — avoid the problem entirely, because each generated class body has its own home object at the right place in the chain. ## Static methods and getters The same rule applies with a different home object. Inside a static method of `Child`, the home object is `Child`, so `super.create()` looks `create` up on `Object.getPrototypeOf(Child)` — the parent class. Inside an accessor, `super.x` reads or writes through the parent's getter or setter with `this` still bound to the current instance, which is how a subclass accessor can wrap the parent's. ## Arrow functions and nested scopes An arrow function has no `[[HomeObject]]` of its own, and `super` inside it resolves lexically to the enclosing method's: ```js class Child extends Parent { greet() { return [1].map(() => super.greet()); // fine } } ``` A nested ordinary `function` expression is not a method definition, so `super` inside it is a `SyntaxError` even though it sits inside a class body. ## Reassigning prototypes at runtime Because lookup goes through the home object's prototype and that prototype is read at call time, changing it changes where `super` lands: ```js Object.setPrototypeOf(Child.prototype, OtherParent.prototype); ``` After this, every `super.x` in `Child`'s instance methods resolves against `OtherParent.prototype`. The home object is fixed; its prototype is not. This is occasionally used by test doubles and hot-reload machinery, and it is a good reason to treat `setPrototypeOf` on a live prototype as a heavy operation rather than a tweak. ## How to reason about it in an interview State the rule as a sentence: *lookup from the home object's prototype, call with the current `this`*. Then demonstrate the divergence with the copied-method example. That single example proves you understand the slot exists, that it is attached to the function rather than the call site, and why the naive `Object.getPrototypeOf(this)` design fails.