This and super binding inside initializers

[jridgewell]

class Base {
    x = 1;
    method() { return 2; }
}

class Sub extends Base {
    z = this.x + super.method();
    constructor() {
      const instance = Reflect.construct(Base, [], new.target);
      new.initialize(instance);
      return instance;
    }
}

const instance = new Sub();
console.log(instance.z)

Just so that we're thinking about it. The this binding should be easy, but I'm not 100% sure how to change the super binding? Does it just work?

[littledan]

I'm having trouble understanding what the problem is. I think it should just work?

[jridgewell]

super binding confuses the hell out of me. I can reason about it when I pretend it's this.constructor.__proto__, but I don't actually know how it works in the spec.

What is super in this case? Or, what is super when I pass in some object literal (and not the result of Reflect.construct)?

[ljharb]

if this becomes rebound, then I’d expect super to; and if not, not.

If not, I’d expect super.method to be the one on Base.prototype (no matter what instance was)

[littledan]

The binding of this will be based on what you pass in, and the binding of the home object will be fixed.

[ljharb]

@littledan wait, so new.initialize alters the binding of this? if so, why is return-override needed?

[littledan]

Yes, the whole idea of the feature is to pass in a different this value to initialize.

Returning something from the super constructor is the "normal" way the subclass instantiation process, and constructors can return whatever object they wabt. The return override trick is just what you get when you combine features. We would have to do something special (and weird) to block it in this case.

[ljharb]

What I meant was this comment:

class Sub extends Base {
    z = this.x + super.method();
    constructor() {
      const instance = Reflect.construct(Base, [], new.target);
      new.initialize(instance);
      assert(this === instance); // this would be true?
      return instance; // and this line can be removed, and it'd do the same thing?
    }
}

[littledan]

Oh, no, I am only talking about the this binding within the initializer, not the constructor.

[ljharb]

ok so, calling new.initialize doesn’t alter the this binding, so I’d also expect the super binding and the method HomeObjects to be unchanged.

[littledan]

The super binding does remain unchanged in the constructor, whereas the this and super bindings are both changed in initializers, and home object bindings are never changed.

[ljharb]

@littledan so super in initializers becomes what, exactly? Would it be the initial value of replacement.__proto__?

[littledan]

See the detailed syntax and semantics described in this section of the explainer. I'm not proposing any changes to the semantics of super.

In particular, new.initialize doesn't set the prototype, it just initializes fields and private methods.