-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #4464: backticked expressions in class body #4668
Fix #4464: backticked expressions in class body #4668
Conversation
db5b2fa
to
f77a98a
Compare
@GeoffreyBooth as I mentioned to you I found a much smaller change that accomplishes the same thing. Edit: I rolled back most of the other changes since they seem to have been 'side-effects' of that approach. |
f77a98a
to
657bdad
Compare
A simpler solution would be great! That's why I wanted you to look at this 😄 Can you push your version on this branch, to update the PR? |
I don't see your commits. |
…ft in the body, not hoisted
0a336f2
to
4ec0db4
Compare
This uses more of the existing machinery for moving class body expressions into the initializer.
4ec0db4
to
1d3af8c
Compare
I had squashed the original one, but I've split it out now. |
@@ -1751,11 +1751,10 @@ exports.Class = class Class extends Base | |||
new Block expressions | |||
|
|||
# Add an expression to the class initializer | |||
# | |||
# NOTE Currently, only methods and static methods are valid in ES class initializers. | |||
# When additional expressions become valid, this method should be updated to handle them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this comment no longer valid?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wavered on it a little. I felt it was confusing since the check now also allows PassthroughLiteral
s, and I didn't want to add that to the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I could go the other way and flesh it out a little to indicate that it's the key method for determining whether something appears in the class initializer or executable body?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think more is better. Maybe even explicitly mention class fields/class properties, that when they reach Stage 4 this is where we detect them. That way future PRs to add things like that look more like your version of this PR and less like mine 😄
It seems I broke the PR by pushing to I reverted |
Fixes #4464, and allows backticks to provide a workaround for class properties (#4552).
This PR treats backticked expressions in a class body as a special case that doesn’t get hoisted; they just get output in the class body:
This allows backticks to be used for the not-yet-finalized feature of class properties, as shown above (#4552); or any other unsupported code people might want to put in a class body:
The special case is triggered only when the entire expression is backticked. A line that mixes backticked and unbackticked code, assuming it doesn’t throw a compiler error, will be output as it is now (in the hoisted class body). And the backticked expressions are always output first, above the rest of the class body. @connec @xixixao