new instantiation design alternatives

Allen Wirfs-Brock allen at
Sun Sep 14 18:54:12 PDT 2014

On Sep 14, 2014, at 4:23 PM, Brendan Eich wrote:

> Kevin Smith wrote:
>> If we want to merge allocation with initialization, then I'm going to want to invoke C# (yet again):
>>    class ColoredPoint extends Point {
>>        constructor(x, y, color) : super(x, y) {
>>           this.color = color;
>>        }
>>    }
> Gotta credt C#'s parents, C++, which would require Point not super.
> I think you are really onto something here. We do not want anything looking like an expression-statement in the constructor body, which besides being verbose has unwanted degrees of freedom (requiring TDZ for `this`, running into the dead code problem Jeff cited, etc.).

the dead code problem (and we can debate whether it is actually a significant problem) goes away with alternative 2 (no automatic mew super in derived class constructors. 

The TDZ constrained `this` is an elegant solution which we had a good consensus on at the last TC39 meeting. Since then we have developed has it further unifies various allocation patterns that come up in JS object constructions.  Everybody really need to really work through all the use cases given in the Gists and similarly work through them all with what every other alternatives they may think would be better. 

> It sure seems to me that we rather want a special form in the constructor head. This came up in ES4.

the C/C# constructor header approach butts heads with other ES features and isn't expressive for the sort of dynamic classes that ES allows.

In terms of headbutting, consider

`constructor({a: x, b: y), [a1,a2,a3,...arest], c ) : super(??, ??) {}//  what do I put here to super call the constructor with only the first two arguments)`


`constructor{a: x, b: y), [a1,a2,a3,...arest], c ) : super(arguments[0], arguments[1]) {}`

but that means that the special header form must allow arbitrary expressions.  Are those expression in the parameter scope of the body scope.

Most importantly, a single constrained expression isn't expressive enough.  The problem, is that a subclass constructor may need to perform arbitrary compelx computations before super newing the its base constructor.  For example, consider a TypeArray subclass constructor that filters various collections passed to to the derived  constructor to produce a simple list iterator that it passed to the  base constructor.

The constrained super expression is a slippery slope that leads you to a cliff. Better to go with the full generality and expressiveness of the function body.

> Separately I agree `this = new super(x, y);` is just crazy long and very likely to be left out in whole or in part (the `new`).

If left-out, programs will fail quickly and noisily (reference errors) especially with the no auto super design alternative.

And this hardly seems like a significant length issue as we are talking about something that at typically occurs only once per subclass with an extends clause. And not even for all subclasses.

and ignoring white space we are taking about either +5 characters ("this=") or 8 characters ("this=new") if you think the alternative is is just "super" without a "new".  But in we addressed why it is really a bad idea to make "super(a,b)"  be a [[Construct]] operation rather than a [[Call]] operation. Basically, JS is currently very consistent in that `new foo()` and `foo()` do not have the same language level meanings.  It would be a big WTFJS if we changed things such that  sometimes the syntax for a [[Call]] really means a [[Construct]].  Especially, if that meaning is dependent upon how the enclosing function was invoked rather than being statically determined.  Example, in the rationale document.

As I mentioned a couple of times in conversations, those of use who worked on developing this design found that the syntax really grows upon you.  It's big advantage is that is is unambiguously explicit.  If you want to invoke a constructor "as a constructor" you always say `new`. `new foo()` or new super(), it doesn't make a difference, `new` always means [[Constructor]]. If you want to invoke a constructor "as a function" you do a normal function invocation.  Again, either `foo()` or `super()`.  It's the same.  The [[Call]] syntax is never repurpose to mean [[Construct]] so there are no special cases to explain or remember.  Also, if you want to designate the `this` value used within a constructor you always explicit say `this=`, whether it is `this = super()' or `this=mayFactoy()` or `this = new Proxy(new super(), {...});`. Again, it is always explicit, no magic `super` calls that magically sets `this` as a side-effect.

It's this explicitness that grows on you.  The code actually says what it means.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list