Closed jeffmo closed 8 years ago
To me it seems like super
property access and this
should be part of the same package. Maybe new.target
would also go along with super
and this
. And, to state the obvious, the super
constructor is disallowed because the initializers are run after the super constructor returns.
@michaelficarra @zenparsing @domenic @allenwb @erights and others: Any thoughts on this question?
My initial intuition is that new.target
is not like this
and super
-properties/methods. Like arguments
, new.target
is more associated with the actual constructor invocation. Whereas this
and super
-properties/methods is more associated with "stuff that happens in relation to class instances".
That is, IMO the grouping is:
this
, super
-properties/methodsarguments
, new.target
, explicit constructor arguments, super()
-construct.Willing to be persuaded otherwise, certainly.
I agree with @domenic's intuition. imo new.target
should only be permitted in a constructor.
I'm uncomfortable with the level of special-casing required here.
I think the grammar for new.target
would have to be special-cased to allow it outside of a function. By default, I'd think it would be disallowed in properties.
@ljharb But we are apparently allowing super
properties outside of a method, which is novel. Again, this is a special case scope.
Per our last meeting, "Initializers run with the semantics of individual anonymous methods with no arguments being run on the class. That explains the scope of this and super property access"
There was general agreement at the last meeting on arguments
and new.target
as well -- but it turns out there is still some concern about this and needs further discussion. That discussion has been happening over in https://github.com/tc39/proposal-class-public-fields/issues/34
Currently we do not have any explicitly notated support for evaluating SuperProperty references in field initializers. Given that
this
is available, it seems it would only be natural to also provide SuperProperty as well.