New ES6 constructor features and semantics: Alternative 2 manual super in derived classes
##Rationale for not allowing unqualifed super in methods.
####Previous ES6 design
Up to now, the ES6 specification has allowed super without a property qualificaton to be used within methods as a short hand for a super-based property access using the same property name as the name of the current method. For example:
class Derived extends Base {
foo() {
super(); //means the same thing as: super.foo();
//do more stuff
}
}
This is a convient short hand because calling the super method of the same name is, by far, the most common use case for super invocation in a method. It is actually quite rare for a method to want to super call any name other than its own. Some languages, that have a super, only allow such unqualified super invocations.
####Apply the new instantiation design to non-class defined constructors.
In looking at what it takes to rationally integrate FunctionDeclaraation/FunctionExpression defined constructors into the new ES6 object instantiation design I've concluded that in order to give new super
and super()
rational meaning inside such basic constructors we need to eliminate the current implicit method name qualification of super in other contexts. I suspect some people will be happy about this, and some will be sad.
There are a couple of things that drove me to this (reluctant) decision.
First (and perhaps least important) is the fact that within a class constructor when somebody says new super
they really mean precisely the constructor that was identified in the extends clause of the actual constructor function. This is also the value used to set the class constructor's [[Prototype]]. new super.consructor
usually means the same thing, but if somebody does rewiring of the prototype chain or modifies the value of the 'constructor' property this may not be the case.
If a constructor is defined using a function definition like:
C.__proto__ = Array;
function C() {
this = new super();
}
C.prototype = {__proto__: Array.prototype,
someNewMetthod() {...}
//note missing constructor property definition
};
we need a semantics for new super
that doesn't depend upon 'toMethod' first being invoked on C or on C.prototype.constructor
being defined. It pretty clear that in a case like this the developer intends that new super()
would invoke Array.[[Construct]].
The interpretation of new super
that meets this criteria and which can be consistently applied to both constructors defined using a class definition and constructors defined using function definitions is that new super
means the same thing as new (<currentFunction>.[[GetPrototypeOf]]()
. In other words, new super
should follow the current constructor function's [[Prototype]] chain. If <currentFunction>.[[Prototype]]
is null it should throw. If <currentFunction>.[[Prototype]]
is Function.prototype it will allocated an ordinary object.
What if somebody writes
C.__proto__ = Array;
function C() {
if (new^) return new super;
return super();
}
I don't think we want the two unqualified super references to bind to different values. Or for super()
to mean different things depending upon whether the enclosing function was invoked via [[Construct]] or [[Call]]. And deleting the first line of C really shouldn't change the semantics of the second line.
Also, I don't think we want the meaning of super()
to change if somebody does:
someObj.foo= C.toMethod(someObj, "foo");
Finally,
class A extends X {
foo() {super()}
}
shouldn't mean something different from:
class A extends X{};
A.prototype.foo = function() {super()}.toMethod(A.prototype, "foo");
As far as I could find, the best way out of this is to completely eliminate implicit method name qualification of super in non-constructor concise methods and only allow unqualifed super in constructors. Basically, you will have to write
class A extends X {
foo() {
super.foo(); //can't say: super()
}
}
if that is what you mean. This make ES6, in this regard, more like Java (and Smalltalk) and less like Ruby.
#Usage Patterns for Basic Constructor Functions
Any functions defined using a FunctionDeclaration, FunctionDeclaration, or a call to the built-in Function constructor can be invoked as a constructor using the new operator. We will call such functions "basic constructors".
function BasicF (a) {
this.foo = a;
}
let obj=new BasicF(42);
assert(Object.getPrototypeOf(obj) === BasicF.prototype);
assert(obj.foo===42);
Because this basic function does not contains an explicit assignment to this, when it is invoked using new it performs default allocation before evaluating its function body. The default allocation action is to allocated an ordinary object using BasicF.prototype as the [[Prototype]] of the newly allocated object. After default allocation, the body of the functon is evaluated with the newly allocated object as the value of this.
This is exactly the same behavior that such a function would have in prior editions of ECMAScript.
The [[Prototype]] of a basic constructor can be set to some other construtor function We will use the term "derived function" to describe basic construtor functions that have had their [[Prototype]] set in this manner and the term "base constructor" to describe a constructor that is the [[Prototype]] value of a derived function.
Turning a basic constructor into a derived constructor by setting its [[Prototype]] does not change the default allocation action of the basic constructor. It still allocates an ordinary object and then evaluates its body with the newly allocated object as the value of this. It does not automatially call the base constructor.
DerivedF.__proto__ = BasicF;
function DerivedF (a,b) {
this.bar = b;
}
assert(DerivedF.__proto__===BasicF);
let obj=new DerivedF(42, 43);
assert(obj.__proto__ === DerivedF.prototype);
assert(obj.hasOwnProperty("foo")===false); //BaseF is not automatiically called.
assert(obj.bar===43);
The above behavior is also identical to that of previous verions of ECMAScript, assuming __proto__
is supported.
If a derived constructor wants to delegate object allocation and initialization to a base constructor it must over-ride default allocation using an expression that invokes the base constructor using the new operator and assign the result to this.
DerivedF2.__proto__ = BasicF;
function DerivedF2 (a,b) {
this = new super(a);
this.bar = b;
}
assert(DerivedF2.__proto__===BasicF);
let objF2 = new DerivedF2(42, 43);
assert((objF2.__proto__ === DerivedF2.prototype);
assert(objF2.hasOwnProperty("foo")); //BaseF was explicitly called and initialized foo.
assert(objF2.foo===42);
assert(objF2.bar===43);
Design Rationale: Basic constructors differ from class constructors in that they always do automatic allocation and initialization of this, even if the constructor logically extends another constructor. This difference is necessary to preserve compatability with existing JavaScript code that uses __proto__
to set the [[Prototype]] of constructor functions. Such code will have been written expecting new to enter the constructor with a fresh ordinary object rather than with this uninitialized in its TDZ.
function ArrayLike () {
this = {__proto__: Array, length: 0}; //instances are ordinary objects with a length property
}
var aLike = new ArrayLike().push(1,2,3,4,5);
Basic constructors may assign to this (this=
) to over-ride their default allocation action, just like constructors defined using a class definition. For example, all of the following class-based examples can be easily rewritten using basic constructors in place of the derived classes:
Permutated Arguments,
ComputedArguments,
Base Not Used,
Proxy Wrapping Base.
####Basic construtor access to new^
The new^ token may be used within a basic constructor to determine if it has been "called as a function" or "called as a constructor" and in the latter case to access the receiver value pass to it via [[Construct]].
See Semantics Summary for an explanation of the new^ token.
function base( ) {
"use strict";
console.log(`in base, this=${this}`);
}
function derived () {
"use strict";
super();
console.log(`in derived, this=${this}`);
}
derived.__proto__=base;
derived( );
//logs: in base, this=undefined
//logs: in derived, this=undefined
The current this value (undefined in this example) is implicitly passed as the this value of a super()
call.
function SelfNewing(...args) {
if (!new^) return new SelfNewing(...args);
this.message = "Created by SelfNewing";
};
console.log(new SelfNewing().message); //logs: Created by SelfNewing
console.log(SelfNewing().message); //logs: Created by SelfNewing
####Anti-pattern: Qualified super references in basic constructors A basic constructor can not use qualified super references unless it has been installed as a method using toMethod or Object.assign.
function f() {
return super.foo()
}
try{f()} // ReferenceError [[HomeObject]] binding not defined.
catch (e) {console.log(e)}; //logs: ReferenceError
var obj={__proto__: {foo(){console.log("foo")}}};
obj.f=f.toMethod(obj);
obj.f(); //logs: foo
toMethod
.constructor
ConciseMethod within a class defintion. It is also allowed within an ArrowFunction within the body of any such a function.There is a Rationale that further explains some of these design changes.
The patterns below progressively explain the key semantic features of this proposal and their uses. A more complete summary of the semantics for this proposal are in Proposed ES6 Constructor Semantics Summary.
A class declaration without an extends clause and without a constructor method has a default constructor that allocates an ordinary object.
class Base0 {};
let b0 = new Base0; //equivalent to: let b0 = Object.create(Base0.prototype);
The most common form of constructor automatically allocates an ordinary object, binds the object to this, and then evaluates the constructor body to initialize the object.
class Base1 {
constructor(a) {
this.a = a;
}
}
let b1 = new Base1(1); //equivalent to: let b1 = Object.create(Base1.prototype);
// b1.a = 1;
Any constructor body that contains an explicit assignment to this does not perform automatic allocation. Code in the constructor body must allocate an object prior to initializing it.
class Base2 {
constructor(x) {
this = [ ]; //create a new exotic array instance
Object.setPrototypeOf(this, new^.prototype);
this[0] = x;
}
isBase2 () {return true}
}
let b2 = new Base2(42);
assert(b2.isBase2()===true);
assert(Array.isArray(b2)===true); //Array.isArray test for exotic array-ness.
assert(b2.length == 1); //b2 has exotic array length property behavior
assert(b2[0] == 42);
Often derived classes want to just use the inherited behavor of their superclass constructor. If a derieved class does not explicitly define a constructor method it automatially inherits its superclass constructor, passing all of its arguments..
class Derived0 extends Base1 {};
let d0 = new Derived0("b1");
assert(d0.a === "b1");
assert(d0.constructor === Derived0);
assert(Object.getPrototypeOf(d0) === Derived0.prototype);
The above definition of Derived0 is equivalent to:
class Derived0 extends Base1 {
constructor() {
this = new super(...arguments);
}
}
Note that the this value of a constructor is the default value of the invoking new expression unless it is explicilty over-ridden by a return statement in the constructor body. (This is a backwards compatabible reinterpretation of legacy [[Construct]] semantics, updated to take into account that the initial allocation may be performed within the constructor body.)
A derived class must explicitly set its this binding. Typically by first invoking its base class constructor using the new operator, to obtain a new instance. It then evaluates the remainder of the derived class constructor using the value returned from the base constructor as the this value.
class Derived1 extends Base1 {
constructor(a, b) {
this = new super(a); //note only a passed to super constructor
this.b = b;
}
};
let d1 = new Derived1(1, 2);
assert(d1.a === 1); //defined in Base1 constructor
assert(d1.b === 2); //defined in Derived1 constructor
A derived class may perform arbitrary computations prior to calling its base constructor, as long as the computations don't reference this. For example, if the derived constructor needs to modify the arguments passed to the base constructor, it must perform the necessary computations prior to invoking the base constructor and assigning the result to thus.
class Derived2 extends Derived1 {
constructor(a, b, c) {
this = new super(b, a);
this.c = c;
}
};
let d2 = new Derived2(1, 2);
assert(d2.a === 2);
assert(d2.b === 1);
assert(d2.c === 3);
class Derived3 extends Derived1 {
constructor(c) {
let a = computeA(), b = computeB(); //note, can't reference 'this' here.
this = new super(a, b);
this.c = c;
}
};
let d3 = new Derived3(3);
assert(d3.c === 3);
class Derived4 extends Base2 {
constructor (a) {
this = Object.create(new^.prototype);
this.a = a;
}
isDerived4() {return true};
}
let d4 = new Derived4(42);
assert(d4.isBase2()===true); //inherited from Base2
assert(d4.isDerived4()===true);; //from Derived4
assert(Array.isArray(d4)===false); //not an exotic array object.
assert(d4.hasOwnProperty("length")===false);
assert(d4.a == 42);
class Derived5 extends Derived1 {
constructor() {return Proxy(new super(...arguments), new^.handler())};
static handler() {
return {
get(target, key, receiver) {
console.log(`accessed property: ${key}`);
return Reflect.get(target, key, receiver);
}
};
};
};
Use of return is appropiate here because we don't need to reference this within the body of the constructor. Using return over-rides the uninitialized this binding.
Additional classes that use different handlers can be easily defined:
class Derived6 extends Derived5 {
static handler() {
return Object.assign({
set(target, key, value, receiver) {
console.log(`set property: ${key} to: ${value}`);
return Reflect.get(target, key, value, receiver)
}
}, super.handler());
};
};
Note that Derived6 doesn't need an explicit constructor method definition. Its automatically generated constructor performs this=new super(...arguments);
.
####An Abstract Base class that can't be instantiated using new
class AbstractBase {
constructor() {
this = undefined;
}
method1 () {console.log("instance method inherited from AbstractBase");
static smethod () {console.log("class method inherited from AbstractBase")};
};
let ab;
try {ab = new AbstractBase} {catch(e) {assert(e instance of TypeError)};
assert(ab===undefined);
Classes derived from AbstractBase must explicitly allocate their instance objects.
class D7 extends AbstractBase {
constructor () {
this = Object.create(new^.prototype); //instances are ordinary objects
}
}
let d7 = new D7();
d7.method1(); //logs message
D7.smethod(); //logs message
assert(d7 instanceof D7);
assert(d7 instanceof AbstractBase);
class D8 extends AbstractBase {};
new D8; //throws TypeError because result of new is undefined
A unique feature of ECMAScript is that a constructor may have distinct behaviors depending whether it is invoke by a new expression or by a regular function call expression.
When a constructor is called using a call expression, the token new^ has the value undefined within the constructor body.
class F0 {
constructor() {
if (new^) console.log('Called "as a constructor" using the new operator.');
else console.log('Called "as a function" using a function expression.');
}
}
new F0; //logs: Called "as a constructor" using the new operator.
F0(); //logs: Called "as a function" using a function expression.
class F1 {
constructor() {
if (!new^) return new F1;
}
}
assert((new F1) instanceof F1);
assert(F1() instanceof F1);
class NonCallableConstructor {
constructor () {
if (!new^) throw Error("Not allowed to call this constructor as a function");
}
}
class F2 {
constructor(x) {
if (new^) {
//called as a constructor
this.x = x;
} else {
//called as a function
return x.reverse();
}
}
};
let f2c = new F2("xy");
let f2f = F2("xy");
assert(typeof f2c == "object") && f2c.x ==="xy");
assert(f2f === "yx");
The distinction between "called as a function" and "called as a constructor" also applies to super invocations.
class F3 extends F2 {
constructor(x) {
if (new^) {
this = new super(x+x); //calls F2 as a constructor
} else {
return super(x) + super(x); //calls F2 as a function (twice)
}
};
let f3c = new F3("xy");
let f3f = F3("xy");
assert(typeof f3c == "object") && f3c.x ==="xyxy");
assert(f3f === "yxyx");
A base class constructor that is known to perform automatic allocation may be called (as a function) by a derived constructor in order to apply the base initialization behavior to an instance allocated by the derived constructor.
class D8 extends Base1 {
constructor(x) {
this = [ ];
Object.setPrototypeOf(this, new^.prototype);
super(x); //note calling super "as a function", passes this,
// and does not do auto allocation
}
}
let d8 = new D8(8);
assert(d8.x==8);
However, care must be taken that the base constructor does not assign to this when "called as a function".
This construction framework breaks object construction into two phase, an allocation phase and an instance initializaiton phase. This framework design essentially duplicates the @@create design originally proposed for ES6. The design of this framework uses a static "@@create" method to perform the allocation phase. The @@create method may be over-ridden by subclass to change allocation behavior. This framework expects subclasses to place instance initialization logic into the consturctor body and performs top-down initializaiton.
Symbol.create = Symbol.for("@@create");
class BaseForCreate{
constructor( ) {
this = new^[Symbol.create]();
}
static [Symbol.create]() {
// default object allocation
return Object.create(this.prototpe);
}}
class DerivedForCreate1 extends BaseForCreate {
//A subclass that over rides instance initialization phase
constructor(x) {
this = new super();
// instance initialization logic goes into the constructor
this.x = x;
}
}
class DerivedForCreate2 extends BaseForCreate{
//A subclass that over rides instance allocation phase
static [Symbol.create]() {
// instance allocation logic goes into the @@create method body
let obj = [ ];
Object.setPrototypeOf(obj, this.prototype);
return obj;
}
}
This construction framework also breaks object construction into two phase, an allocation phase and an instance initializaiton phase. The design of this framework uses the constructor method to perform the allocation phase and expects subclasses to provide a seperate initializaiton method to peform instance initialization. The initialize methods control whether initialization occur in a top-down or buttom-up manner.
class BaseForInit {
constructor(...args) {return this.initialize(...args)}
initialize () {return this}
}
class DerivedForInit1 extends BaseForInit {
//A subclass that over rides instance initialization phase
initialize(x) {
// instance initialization logic goes into an initialize method
this.x = x;
}
}
class DerivedForInit2 extends BaseForInit {
//A subclass that over rides instance allocation phase
constructor(...args) {
// instance allocation logic goes into the constructor body
this = [ ];
Object.setPrototypeOf(this, new^.prototype);
return this.initialize(...args);
}
}
class DerivedForInit3T extends DerivedForInit1 {
//A subclass that over rides instance initialization phase
//and performs top-down super initialization
initialize(x) {
super.initialize(); //first perform any superclass instance initization
this.x = x;
}
}
class DerivedForInit3B extends DerivedForInit1 {
//A subclass that over rides instance initialization phase
//and performs bottom-up super initialization
initialize(x) {
this.x = x; //first initialize the state of this instance
super.initialize(); //then perform superclass initization
}
}
class Anti1 {
constructor() {
return Object.create(new^.prototype);
//better: this = Object.create(new^.prototype);
//or: this = {__proto__: new^.prototype};
}
}
JavaScript has always allowed a constructor to over-ride its autmatically allocated instance by returning a different object value. That remains the case with this design. However, using return in this manner (instead of assigning to this) may be less efficient because the constructor is specified to still automatically allocates a new instance.
class Anti2a extends Base {
constructor(y) {
this.y = y;
}
}
new Anti2a(0); //reference error because this is in its TDZ
Derived classes don't perform automatic allocation, they must either perform this = new super(...arguments), localy allocate an object and assign it to **this, or explicitly return an object as the value of the constructor.
class Derived2Bad extends Derived1 {
constructor(a, b, c) {
this = /*new*/ super(b, a); //what if we forget to put in new
this.c = c;
}
};
new Derived2Bad(1,2,3); //ReferenceError
This is a derived constructor so it doesn't perform automatic allocation and this is initially uninitialized. It assigns to this but the super() call in its first statement implicitly references this before it is initialized so a ReferenceError exception will be thrown.
This Gist presents a new design of class-based object construction in ES6 that does not require use of the two-phase @@create protocol.
One of the characteristics of this proposal is that subclass constructors must explicitly super invoke their superclass's constructor if they wish to use the base class' object allocation and initialization logic.
An alternative version of this design automatically invokes the base constructor in most situations.
In addition to the material below, there is a seperate design rationale covering several key features that are common to both designs.