Class static
blocks provide a mechanism to perform additional static initialization during class
definition evaluation.
This is not intended as a replacement for public fields, as they provide useful information for static analysis tools and are a valid target for decorators. Rather, this is intended to augment existing use cases and enable new use cases not currently handled by that proposal.
Stage: 4
Champion: Ron Buckton (@rbuckton)
For detailed status of this proposal see TODO, below.
- Ron Buckton (@rbuckton)
The current proposals for static fields and static private fields provide a mechanism to perform
per-field initialization of the static-side of a class during ClassDefinitionEvaluation, however
there are some cases that cannot be covered easily. For example, if you need to evaluate statements
during initialization (such as try..catch
), or set two fields from a single value, you have to
perform that logic outside of the class definition.
// without static blocks:
class C {
static x = ...;
static y;
static z;
}
try {
const obj = doSomethingWith(C.x);
C.y = obj.y
C.z = obj.z;
}
catch {
C.y = ...;
C.z = ...;
}
// with static blocks:
class C {
static x = ...;
static y;
static z;
static {
try {
const obj = doSomethingWith(this.x);
this.y = obj.y;
this.z = obj.z;
}
catch {
this.y = ...;
this.z = ...;
}
}
}
In addition, there are cases where information sharing needs to occur between a class with an instance private field and another class or function declared in the same scope.
Static blocks provide an opportunity to evaluate statements in the context of the current class declaration, with privileged access to private state (be they instance-private or static-private):
let getX;
export class C {
#x
constructor(x) {
this.#x = { data: x };
}
static {
// getX has privileged access to #x
getX = (obj) => obj.#x;
}
}
export function readXData(obj) {
return getX(obj).data;
}
Proposal: https://github.com/tc39/proposal-private-declarations
The Private Declarations proposal also intends to address the issue of privileged access between two classes, by lifting the private name out of the class declaration and into the enclosing scope. While there is some overlap in that respect, private declarations do not solve the issue of multi-step static initialization without potentially exposing a private name to the outer scope purely for initialization purposes:
// with private declarations
private #z; // exposed purely for post-declaration initialization
class C {
static y;
static outer #z;
}
const obj = ...;
C.y = obj.y;
C.#z = obj.z;
// with static block
class C {
static y;
static #z; // not exposed outside of class
static {
const obj = ...;
this.y = obj.y;
this.#z = obj.z;
}
}
In addition, Private Declarations expose a private name that potentially allows both read and write access to shared private state
when read-only access might be desireable. To work around this with private declarations requires additional complexity (though there is
a similar cost for static{}
as well):
// with private declarations
private #zRead;
class C {
#z = ...; // only writable inside of the class
get #zRead() { return this.#z; } // wrapper needed to ensure read-only access
}
// with static
let zRead;
class C {
#z = ...; // only writable inside of the class
static { zRead = obj => obj.#z; } // callback needed to ensure read-only access
}
In the long run, however, there is nothing that prevents these two proposals from working side-by-side:
private #shared;
class C {
static outer #shared;
static #local;
static {
const obj = ...;
this.#shared = obj.shared;
this.#local = obj.local;
}
}
class D {
method() {
C.#shared; // ok
C.#local; // no access
}
}
- C#: Static Constructors
- Java: Static Initializers
class C {
static {
// statements
}
}
- A
static {}
initialization block creates a new lexical scope (e.g.var
,function
, and block-scoped declarations are local to thestatic {}
initialization block. This lexical scope is nested within the lexical scope of the class body (granting privileged access to instance private state for the class). - A class may have any number of
static {}
initialization blocks in its class body. static {}
initialization blocks are evaluated in document order interleaved with static field initializers.- A
static {}
initialization block may not have decorators (instead you would decorate the class itself). - When evaluated, a
static {}
initialization block'sthis
receiver is the constructor object of the class (as with static field initializers). - It is a Syntax Error to reference
arguments
from within astatic {}
initialization block. - It is a Syntax Error to include a SuperCall (i.e.,
super()
) from within astatic {}
initialization block. - A
static {}
initialization block may contain SuperProperty references as a means to access or invoke static members on a base class that may have been overridden by the derived class containing thestatic {}
initialization block. - A
static {}
initialization block should be represented as an independent stack frame in debuggers and exception traces.
// "friend" access (same module)
let A, B;
{
let friendA;
A = class A {
#x;
static {
friendA = {
getX(obj) { return obj.#x },
setX(obj, value) { obj.#x = value }
};
}
};
B = class B {
constructor(a) {
const x = friendA.getX(a); // ok
friendA.setX(a, x); // ok
}
};
}
The following is a high-level list of tasks to progress through each stage of the TC39 proposal process:
- Identified a "champion" who will advance the addition.
- Prose outlining the problem or need and the general shape of a solution.
- Illustrative examples of usage.
- High-level API.
- Initial specification text.
- Transpiler support (Optional).
- Babel
v7.12.0
- TypeScript
v4.4 beta
(TypeScript Playground)
- Babel
- Complete specification text.
- Designated reviewers have signed off on the current spec text.
- The ECMAScript editor has signed off on the current spec text.
For up-to-date information on Stage 4 criteria, check: #48
- Test262 acceptance tests have been written for mainline usage scenarios and merged.
- Two compatible implementations which pass the acceptance tests:
- SpiderMonkey — Partially shipping Shipping behind a flag in 92, Intent to ship unflagged in 93:
- V8 — Shipping unflagged (at least as of 9.4.146):
- SpiderMonkey — Partially shipping Shipping behind a flag in 92, Intent to ship unflagged in 93:
- A pull request has been sent to tc39/ecma262 with the integrated spec text.
- The ECMAScript editor has signed off on the pull request.