In a JavaScript class, what is the difference between `super(...)` and `super.someMethod()`, and where is each one allowed to appear?

## One keyword, two forms The grammar treats `super` as two separate productions, and the rules differ for each. ### The super call: `super(...)` This one constructs. It finds the parent constructor — the prototype of the constructor currently running — invokes it, and binds the resulting object as `this` in the derived constructor. It is a statement about *object creation*, so it is legal in exactly one position: inside the constructor of a class declared with `extends`. ```js class Animal { constructor(name) { this.name = name; } } class Dog extends Animal { constructor(name) { super(name); // runs Animal's constructor this.legs = 4; } } ``` Everywhere else it is a `SyntaxError`, caught before the code runs: - in the constructor of a class with no `extends` clause; - in a normal method, even of a derived class; - in a standalone function. If a derived class declares no constructor, the engine supplies `constructor(...args) { super(...args); }`, so the call still happens — you just did not write it. ### The super property: `super.x` This one looks up. `super.speak()` starts the search at the parent of the object the method was defined in, finds `speak` there, and calls it with the current `this`. That last part is the whole point: the parent's code runs against the current instance, so it sees the subclass's own state. ```js class Animal { speak() { return `${this.name} makes a sound`; } } class Dog extends Animal { speak() { return super.speak() + ' (a bark)'; } } new Dog(); // this.name inside Animal#speak is the Dog's name ``` Without it, calling `this.speak()` inside the override would call the override again and recurse until the stack overflows — a classic first-week bug. The property form is legal much more widely than the call form: - instance methods, getters and setters; - static methods, where it reaches the parent **class**'s statics rather than the parent's prototype; - concise methods of ordinary object literals, not only classes; - a class with no `extends` at all, where the parent is `Object.prototype`, so `super.toString()` works. It is also **not** limited to reading. `super.x = 1` performs a set that starts its lookup on the parent — relevant when the parent defines a setter — though the property lands on `this`, not on the parent. ### Where neither form works Both forms need the surrounding function to be a *method definition*. A function expression assigned to a property is not one: ```js const obj = { greet: function () { return super.greet(); } }; // SyntaxError ``` An arrow function is a special case for the property form: it has no `super` of its own but inherits the enclosing method's, so `super.speak()` inside a callback written as an arrow inside a method is fine. ## The ordering interaction The two forms meet in one place. Because `super.x()` calls the parent method with `this` as receiver, and `this` does not exist before the super call, a derived constructor cannot use the property form before the call form: ```js class Dog extends Animal { constructor(name) { super.speak(); // ReferenceError: this is not initialised yet super(name); } } ``` So the ordering rule you learn for `super(...)` also constrains `super.x` inside constructors. ## How to answer this crisply Say: "`super(...)` runs the parent constructor and only exists in a derived constructor; `super.method()` calls the parent's version of a method with the current `this` and works in any method, including static ones and even in a class with no parent." Then give the recursion example — `this.speak()` versus `super.speak()` inside an override — because it shows you know *why* the property form exists rather than just where it is legal.