Closed ExE-Boss closed 4 years ago
This is a result of classes themselves not properly supporting null. You can, however, extend a class that extends null and uses your workaround.
What's the glitch in the null
support?
The issue is that a constructor that extends null
ends up with its [[ConstructorKind]]
internal slot set to derived
instead of base
, which results in the implicit constructor being constructor(...args) { super(...args); }
and the this
binding being uninitialized instead of OrdinaryCreateFromConstructor(newTarget, "%Object.prototype%")
.
This is being fixed in issue https://github.com/tc39/ecma262/issues/1036 (PR: https://github.com/tc39/ecma262/pull/1321).
I get it. Now just out of curiosity, why was class
designed that way? It seems like it would've made things cleaner for there to never be a [[ConstructorKind]]
, for all actions to happen as if "derived" were the only kind, for the class base to always be either Object
, null
, or user specified, and for super()
to be an internal function that automatically handles the special case of a null
base. So why split the situation into something that requires 2 different constructor types?
Just thought about it. That's questions better targeted on es-discuss...
Yeah, classes extending null is sort of generally broken, unfortunately. See https://github.com/tc39/ecma262/pull/1321 for some further discussion. Closing this issue, as it's not about class fields.
With public fields, you can at least do:
But with private fields, you can’t use the
Object.create
work‑around.It’d be so much easier if:
and
didn’t throw.
That would allow class fields to also be used with
extends null
: