Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Normative: Define private names at the beginning of the class #269

Merged
merged 1 commit into from
Oct 3, 2019

Conversation

littledan
Copy link
Member

Private names are logically defined during the whole class execution,
not only after the definition is reached. This patch properly hoists
the private name definition, to avoid an unintentional and confusing
TDZ condition.

Closes #263

Private names are logically defined during the whole class execution,
not only after the definition is reached. This patch properly hoists
the private name definition, to avoid an unintentional and confusing
TDZ condition.

Closes #263
@caitp
Copy link

caitp commented Sep 13, 2019

lgtm

@syg
Copy link

syg commented Oct 3, 2019

We reached consensus on this PR in the October 2019 TC39.

@littledan littledan merged commit 2c5f6de into master Oct 3, 2019
joyeecheung added a commit to joyeecheung/test262 that referenced this pull request Oct 4, 2019
leobalter pushed a commit to tc39/test262 that referenced this pull request Oct 8, 2019
caiolima added a commit to caiolima/webkit that referenced this pull request Oct 11, 2019
definition. This aligns the implementation with the specification
change done in tc39/proposal-class-fields#269.
It is necessary to create and add Private symbols during the inital phase
of class definition, because computed properties can try to access a private
member. In this case, we need to fail with TypeError because it is
an access to a not installed private field.
littledan added a commit to tc39/proposal-static-class-features that referenced this pull request Jan 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Usage of private member inside computed properties
4 participants