super in constructor should be distinct (Re: (Weak){Set|Map} subclassing)

Allen Wirfs-Brock allen at
Wed Dec 5 11:40:13 PST 2012

On Dec 5, 2012, at 5:45 AM, Herby Vojčík wrote:

> Allen Wirfs-Brock wrote:
>> super(...) is just shorthand for super.constructor(...) (when it
>> occurs in a constructor) so it is just a use of [[Call]]. No magic.
> [[Call]]/[[Init]] aside.
> After reading the spec, it is really so that super(...) in constructor is in fact super.constructor(...), because
> - constructor has MethodName "constructor"
> - super(...) has generic super[MethodName](...) semantics.
> IOW, constructor is compiled as any other method with respect to semantics of its code (it gains its [[Construct]] and .prototype magic later, but these are external and do not touch the code).
> It is bad for two reasons:

This is rehashing old territory, but let's go again...

> 1. It will fail. There is lot of examples of code like:
>  function Foo() { ... }
>  Foo.prototype = Object.create(Bar.prototype);
>  // or even (!!!) Foo.prototype = new Bar();
>  Foo.prototype.baz = function () {...};
>  ...
> all over the web, in libraries etc.
> Some people add "Foo.prototype.constructor = Foo;" there, but some don't. Now you see what happens if I try to use the new class:
>  class Quux extends Foo {
>    constructor() { ....; super(...); ... }
>  }

If you are subclassing Foo,  then you better have some understanding that Foo is a well-formed "class-like" object.  Or, from another perspective, not adding a "constructor" property to Foo.prototype is explicating stating that it does not participating in super delegation of calls to "constructor".

In the past, there was minimal penalty to not maintaining the Foo.prototype to Foo link via the "constructor" property. In ES6, this changes.  Fortunately, there is really no reason to use the explicit class wiring pattern because a class definition does exactly the same thing for you.

In any case, you are defining the constructor that contains the super refernce.  If you are subclass something that is potentially malformed WRT  prototype.constructor, then don't use super.  Instead, fall back to doing,...)

> super(...) call fails, because there is no Foo.prototype.constructor.

I't will get an inherited constructor property value, probably the one from Object.prototype

> What's additional risk, the .constructor can be writable/configurable, so something may be injected / it may be deleted. It is not what developers assume. This relates to the:

We discussed making the .constructor property of the prototype object created by a class definition non-writable/non-configurable but in the end the consensus was to match what chapter 15 built-ins do, which is writable/configurable.  (But note that the prototype property of a class created constructor is non-writable/-non-configurable.  On a related note, I'm considering whether built-in @@create methods should be non-writable/non-configurable.  I can see arguments for both sides of that choice).

However, in general JS has very mutable objects and if you start mutating basic relationships,  things may behave oddly.  This relates to all uses of super, not just in constructors.

> 2. It is not right (imho). Constructors are not methods (is there a movement of making them into ones? I doubt, constructor methods are too in-grained in the ECMAScript structure).

Well, in ES a method is defined to be a property with a function as its value.  So, Quux.prototype.constructor is a method, by that definition.

> Constructors are not methods, they are much more external to the class. They _are_ the class, so what nearly every developer assumes when calling super(...) in the constructor with extends Foo to call Foo. Not Foo.prototype.constructor, which is way too brittle.

Note that constructors are invoked by [[Construct]], as if they, were a method.  Specifically the method is [[Call]]'ed with the this value set to the new instance.  So this.baz() within a constructor function is a method call on an instance.  So is this.constructor().

Since super(...) currently doesn't exist in JS, I don't think we can say what it means to nearly every developer other than that currently it means produce a syntax error.  In the future, what super(...) should mean, anywhere in ES code, is do a super invoke using the property name of the currently executing method.  For constructors, that name is "constructor".

> It is the common practice now, Foo.apply(this, arguments) or, ...). The ES6 super(...) does something else.

It's common ES<6 practice, to do this in any method that needs to approximate super call behavior.  But it is not how ES6 super is defined.  One specific difference is that ES6 super correctly rebinds if __proto__ is used to change the [[Prototype]] of either the class prototype or the constructor object itself (which is relevant to class-side methods)

> Therefore, I propose super(...) has different semantics for constructor methods*. It should do roughly (ctr being the constructor function):

Note you are saying that (only) in constructors, super() and super.constructor() have different semantics then they do in other methods(actually we are talking about unqualified and qualified super references in general) . Or do you only want to allow unqualified super in constructors and to disallow it in ordinary methods.  eg, the following would be illegal:

class Quux extends Foo {
   someMethod() {super()} // syntax error, unqualified super in a non-constructor method}

> 1. Get [[Prototype]] of ctr into proto, fail if problem.
> 2. If proto is constructor function,
>  2.1. [[Call]]** proto with thisArg of this, and argument list equal to super(...) argument list
>  2.2. return the completion of 2.1.
> 3. Otherwise, throw.***

think about potential __proto__ rewiring issues. 
>> Allen
> Herby
> * That is, I'd like to see it in freeform constructor methods as well. Only with super(...) shortened form. It's semantics is straightforward and prompts replacing, ...) with saner super(...); of course, one must rewire Foo.__proto__ = Bar; to get this. May help the transition and understanding that class has constructor inheritance as well, not only prototype inheritance.

I'd be fine with allowing super in regular Function definitions.  Others aren't.  However, I would not want super in such declaration to make this sort of constructor usage assumption. A free standing function is just as likely to be plugged in as a "method" as it is as an constructor".  One advantage of such unqualified super references in function declarations (if we ever allow them) is that they are independent of any name in the source code.  When the function is super bound to an object (which is necessary to make super work at all) it picks up the actual property name used for that object. For example,

//hypothetical, doing things that ES6 currently does not allow:
function loggerMethod(...args) { console.log("called on ", this); return super(...args)}

Reflect.defineMethod(someInstance, "someMethod", loggerMethod);  //logs and calls super.someMethod
Reflect.defineMethod(someInstance, "anotherMethod",loggerMethod);  //logs and calls super.anotherMethod

> ** Or [[Init]] if adopted.
Unlikely, @@call + [[Call]] seem just fine.
> *** Alternatively, revert to super.constructor(...). I don't like it, though.

There are a lot of design trade-offs involved to incorporate super into ES. The issues you bring up was considered in arriving at the current design.  So far, your arguments haven't convinced me that we've made the wrong trade-offs. In fact, it has re-enforced (for me) that we have probably made the right ones.  We could go through a process that reexamining it.  But consensus is fragile (within TC39 and anywhere else) and at some point we need to be content with what we have and move on to new issues.  In this light, I really don't want to get into another round of re-engineering super.

I think you may have a reasonable point about the integrity of the Foo.prototype.constructor relationship established by class definitions.  I originally proposed that the constructor property of such prototype objects should be non-writable/non-configurable.  However, at the July meeting we decided to make it be consistent with the existing chapter 15 classes which have writable/configurable constructor properties.  There is a reasonable argument based both upon internal consistency and flexibility for monkey patching behind that decision.  I would still be fine with making them non-writable/non-configurable.  But, without that, you still have the freedom to "freeze" Foo,prototype.constructor for your Foo function if you really are worried about the integrity of super references in the constructor.  If so you probably are also worried about the integrity of all of your methods, so you might as well freeze Foo.prototype.


More information about the es-discuss mailing list