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

Herby Vojčík herby at
Wed Dec 5 13:28:06 PST 2012

Allen Wirfs-Brock wrote:
> 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.
>> 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

Apart from rewiring constructor, it is. It is instantiated with new, 
it's .prototype is filled with methods... Just, author did not rewire 
constructor. Because, it's a burden and no one really needs .constructor 

> perspective, not adding a "constructor" property to Foo.prototype is
> explicating stating that it does not participating in super
> delegation  of calls to "constructor".

I'd argue this is simply not true. The construct was in good faith 
created as a class-like one. It is just not 100%, one previously really 
unnecessary invariant wasn't preserved.

> 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

Kind of breaking change, when taking into account all those "non-classy 
classes" out there.

> explicit class wiring pattern because a class definition does exactly
> the same  thing for you.

I am talking legacy code here.

Maybe at least Reflect.fixClass(Foo) would help to mitigate it (call it 
before on invalid foreign class, it will rewire if it's not right; I 
think rewiring both Class.prototype.constructor as well as Class.__proto__).

But adding API just to help with transition seems a little strange.

> 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,...)

Hm. It would be better if super(...) could be used in subclassing those 
legacy classes, too.

>> 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

Oh. Yes. But not a lot better. Still not what expected. But yes, it 
won't fail.

>> 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).

Hard one. But rather be on the side dynamic side. You can change the 
constructor, you can change the (other) methods by manipulating the 
prototype, even if it in itself is fixed. You should be able to change 
@@create as well in that case.

> 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.

Hm. Too formal. Not every function in an object prototype is a method; 
it may be just put there as a value which is fetched and used otherwise 
(as a node.js callback, say).

For me, method is such a function that is meant to be called in the 
receiver.method(...) way (directly or indirectly via .call and .apply, 
doesn't matter).

Quux.prototype.constructor is questionable here. Since it is in 
.prototype, it can be called as instance.constructor(...), but is it 
meant to be used this way? Some (including me) say "no, it is obviously 
meant to be called via new Class(...)", other may say "yes, since using 
this for sane reasons is enough to be a method".

(I don't see, ...) as a case for method-ness, it's a 
simple workaround made pattern, a workaround for not having super(...) 
yet. IMO)

>> 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

Well, for case of constructors, we can; imnsho, they think that
is the same as the current practice of:
   Foo.apply(this, args).

The case of methods are unqualified super(...) is a little less obvious 
(will write more below).

> 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".

I see the elegance and DRYness of this approach; I like it from the 
technical point of view. But the semantics is not quite right for me.

>> 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)

This gets strange here. {Sub,Super}Class.prototype is non-conf/non-wr. 
So you probably mean SubClass.__proto__ and 
SubClass.prototype.__proto__. Correct me if I did not understand something.

I understand the "is relevant to class-side methods" is about rewriting 
SubClass.__proto__, I see and understand and everything of it is ok, but 
it is a "plain method call super", eg. not the "inside constructor" 
scenario. There everything is fine.

When "in constructor", the real clash of our two view is really visible 
(and everywhere else it's unproblematic). The problem is there are two 
__proto__s (the ones I mentioned above). You say that when they are 
changed / out-of-sync / in whatever-else-nonstandard situation, then the 
authoritative source of super-constructor for the SubClass constructor 
should be SubClass.prototype.__proto__.constructor (that is, 
this.prototype.__proto__.constructor); and I am saying it should be 
SubClass.__proto__ itself.

There is absolutely no problem with qualified super call between our 
views. The only differing question is who is the superconstructor for 
the SubClass.

So I can counterargument that the existing semantics of super(...) in 
constructors fail for the case when SubClass.__proto__ is rewired.

>> 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}
> }

Yes, in fact, unqualified calls in plain methods smell a bit for me.

I really understand how they can help with reuse and ease some 
refactoring scenarios, but I am not content with it. Seems like way too 
implicit. I'd be better off with only explicit here.

But I feared to open this, it would be too much.

>> 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.

As I said earlier, I in fact care for __proto__ rewiring, just I think 
for superconstructor the Class.__proto__, that is, constructor-side 
inheritance seems to me as the authoritative source.

But I see it may create problems for "extends nonConstructor" classes. Hm.

>>> 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

When unqualified super would only means "invoke super-constructor", then 
it won't create clash (could even throw when known not to be called as 
part of new/super).

> references in function declarations (if we ever allow them) is that
> they are independent of any name in the source code. When the

I understand, but feel bad about it.

> 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.

Hm. It is understandable.

> 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.

Not really, I see them really a bit differently. Methods are presumed to 
be patched. But changing a superclass just by changing .constructor in 
superclass is very strange. I mean, it breaks the invariant, unless I 
also rewire the SubClass.__proto__ itself. And we're again in chicken 
and egg.
> Allen


More information about the es-discuss mailing list