Add support for class private methods #703

Qantas94Heavy · 2017-08-29T13:15:23Z

Q	A
Bug fix?	no
Breaking change?	no
New feature?	yes
Deprecations?	no
Spec compliancy?	no
Tests added/pass?	yes
Fixed tickets
License	MIT

This adds support for private methods, as described in https://github.com/littledan/proposal-private-methods.

I haven't made an issue for this proposal yet, but if we want it to be separate from #540, I can do so.

An update to the #plugins part of the readme. Add a new entry to that list for the new plugin flag (and link to the proposal)
If any new nodes or modifications need to be added to the AST, update ast/spec.md
Make sure you use the this.hasPlugin("plugin-name-here") check so that your new plugin code only runs when that flag is turned on (not default behavior)
Add failing/passing tests according to spec behavior

I'll also need to submit changes to babel-types to match up with this PR.

NOTE: There's still a little bit I'm not exactly sure about (tick means handled):

There's some points where this code "eats" the # then throws the error, while in other parts it throws the error without "eating" the #.
This might need a few more tests.
One of the existing ASI tests seems to fail (fixtures/experimental/class-private-properties/asi-failure-inline) because the error message doesn't include expected ;, but the error is still thrown in the same position in the test file. (edit: changed test to match new message)

jridgewell

Woo!

jridgewell · 2017-08-29T18:01:48Z

ast/spec.md

+  type: "ClassPrivateMethod";
+  key: Identifier;
+  kind: "method" | "get" | "set";
+  computed: boolean;


Can't be computed.

jridgewell · 2017-08-29T18:02:15Z

ast/spec.md

+  kind: "method" | "get" | "set";
+  computed: boolean;
+  static: boolean;
+  decorators: [ Decorator ];


Also need async and generator flags.

Would that be needed for the normal ClassMethod as well?

jridgewell · 2017-08-29T18:02:41Z

ast/spec.md

@@ -1049,6 +1050,19 @@ interface ClassMethod <: Function {
 }
 ```

+## ClassMethod


Rename to ClassPrivateMethod

jridgewell · 2017-08-29T18:03:27Z

src/parser/expression.js

+  parseClassPrivateName(
+    prop: N.ClassPrivateProperty | N.ClassPrivateMethod,
+  ): N.Expression {
+    prop.computed = false;


Let's delete this.

jridgewell · 2017-08-30T00:07:50Z

src/parser/statement.js

+        // eaten the #, but in other cases we haven't. How to solve?
+        this.expectPlugin("classPrivateMethods");
+        // private "normal" method
+        method.kind = "method";


Can we hoist this to the beginning of the this.isClassMethod() if statement?

Confused about where exactly you want this part to be moved to.

Before the if (isPrivate).

jridgewell · 2017-08-30T00:11:18Z

src/parser/statement.js

+    const isPrivate = this.eat(tt.hash);
+
+    if (isPrivate) {
+      this.expectOnePlugin(["classPrivateProperties", "classPrivateMethods"]);


I think we need to do this before eating the hash.

jridgewell · 2017-08-30T00:13:59Z

src/parser/statement.js

+      if (this.match(tt.hash)) {
+        // private getter/setter
+        this.expectPlugin("classPrivateMethods");
+        // The private # wouldn't have been eaten as the "async" was in front of it.


Comment is incorrect.

Huh? Maybe my wording was confusing.

What I'm trying to say is that it's now being eaten, but it wasn't detected as being "private" in the code above (let isPrivate = ...). Is that wrong?

The "async" part is incorrect. We're in the "get"/"set" path here.

jridgewell · 2017-08-30T00:14:48Z

src/parser/statement.js

+        this.expectPlugin("classPrivateMethods");
+        // The private # wouldn't have been eaten as the "async" was in front of it.
+        this.next();
+        // The so-called parsed name would have been "async": get the real name.


Comment again.

jridgewell · 2017-08-30T00:15:43Z

src/parser/statement.js

+          false,
+          /* isConstructor */ false,
+        );
+        this.checkGetterSetterParamCount(method);


I think this should apply to private accessors, too.

jridgewell · 2017-08-30T00:17:32Z

src/types.js

+  ClassMethodOrDeclareMethodCommon & {
+    type: "ClassPrivateMethod",
+    key: Identifier,
+    static: false,


Should be boolean, right?

Does this need static in the first place? If not, how would I handle that in terms of types?

Oh, it's already in ClassMethodOrDeclareMethodCommon, so we can just drop this line.

jridgewell · 2017-08-30T00:20:18Z

src/parser/statement.js

-    } else {
-      node.value = null;
-    }
+    if (node.computed !== undefined) node.computed = undefined;


What's this for?

Yeah, that was a dodgy hack for some test failure because I had set computed elsewhere by accident. I've fixed this now.

littledan

This seems like a correct implementation of the grammar to me!

One surprising thing to me here, which I unfortunately missed in the earlier Private Fields PR, is that there's no single AST node for a private name. Instead, an Identifier is used inside of various different node types--previously, ClassPrivateProperty and PrivateName, now also ClassPrivateMethod. I would've expected that ClassPrivateProperty and ClassPrivateMethod would contain a PrivateName which contains an Identifier, instead of directly containing the Identifier.

I assume that the private methods plugin will be responsible for throwing early errors (such as duplicate method definitions); is that right?

I appreciate the tests here. Although I can think of some more tests for syntax edge cases, maybe those are best developed in test262.

nicolo-ribaudo · 2017-08-30T11:01:30Z

src/parser/statement.js

+
+      if (isPrivate) {
+        // TODO: seems a bit inconsistent error throwing: in some cases we've already
+        // eaten the #, but in other cases we haven't. How to solve?


You could make expectPlugin accept an optional pos parameter (like unexpected does) and pass node.start to it.

nicolo-ribaudo · 2017-08-30T11:03:23Z

src/parser/statement.js

@@ -1009,21 +1019,43 @@ export default class StatementParser extends ExpressionParser {
      return;
    }

+    const isPrivate = this.match(tt.hash);
+    if (isPrivate) {
+      this.expectOnePlugin(["classPrivateProperties", "classPrivateMethods"]);


Instead of throwing here, you can wait until it is known if the node is a property or a method (to give a more specific error message).

nicolo-ribaudo · 2017-08-30T11:08:49Z

src/parser/statement.js

+    method: N.ClassMethod,
+    isGenerator: boolean,
+    isAsync: boolean,
+    isConstructor: boolean,


Can this ever be true?

No. Not only that, it should be a syntax error; see below.

Removed (not sure why it's not saying it's outdated).

bakkot

If I'm reading it right, this allows methods and fields named #constructor. (That appears to have been behavior inherited from #609, which was right at the time but changed in tc39/proposal-class-fields@e7d009b.) It shouldn't, for fields or methods. Could you have parseClassPrivateName throw in that case, and add a test or two?

Otherwise looks good to me.

jridgewell · 2017-09-01T19:21:43Z

src/parser/expression.js

+      // TODO: if no plugin and is PrivateName, should error be handled here or elsewhere?
+      if (prop.key.type !== "PrivateName") {
+        // ClassPrivateProperty is never computed, so we don't assign in that case.
+        prop.computed = false;


prop here is a MemberExpression? In that case, it should always be set to false.

I think the method signature says it's a Class[Private]Property or Class[Private]Method.

jridgewell · 2017-09-01T19:23:25Z

src/parser/statement.js

+      if (isPrivate) {
+        this.expectPlugin("classPrivateProperties", key.start);
+        // Private property
+        classBody.body.push(this.parseClassPrivateProperty(prop));


Can we make a #pushClassPrivateProperty?

Done -- should the two be merged or remain separate?

jridgewell · 2017-09-01T19:23:41Z

src/parser/statement.js

+          method,
+          false,
+          false,
+          isConstructor,


Can't be true.

Qantas94Heavy · 2017-09-02T13:08:00Z

I've done some updates to the PR -- will squash later once review done.

While I'm at it, I'm just wondering whether the one test failure is important or not.

This roughly equivalent non-private code just throws Unexpected token (2:4):

class A {
  a b;
}

Do we need it to check whether a semicolon should be there, and if so, how would I go about doing that?

bakkot · 2017-09-02T15:34:44Z

@Qantas94Heavy, I don't think it's important that the failure says Unexpected token, expected ; vs just Unexpected token, especially given that the latter is what happens with regular properties. I'd just fix the test.

jridgewell · 2017-09-06T02:02:20Z

src/parser/statement.js

+    const isSimple = key.type === "Identifier";
+
+    // TODO: should these be merged into pushClassProperty?
+    const handleClassProperty = () => {


This could just be inlined into the callsites.

jridgewell

Oh, sorry, we need to update https://github.com/babel/babylon/pull/703/files#diff-aaeb808425fc8034ffaa66c89d53cf0aR1082. That's a PrivateName now, right?

This commit adds parser support for the TC39 Stage 2 Private Methods proposal. This commit also changes "key" in ClassPrivateProperty from an Identifier to a PrivateName, as well as disallowing #constructor as a valid private field name.

This also removes a test from the Test262 whitelist that failed before the changes for private methods support and now passes.

These should be treated as regular methods and not special get/set/async behaviour.

Qantas94Heavy · 2017-09-06T11:34:23Z

@jridgewell right, updated.

Qantas94Heavy changed the title ~~WIP: Add support for class private methods~~ Add support for class private methods Aug 29, 2017

hzoo requested review from littledan and bakkot August 29, 2017 22:01

hzoo added the Spec: Class Fields label Aug 29, 2017

jridgewell approved these changes Aug 30, 2017

View reviewed changes

jridgewell reviewed Aug 30, 2017

View reviewed changes

Qantas94Heavy force-pushed the private-methods branch from c367d80 to d21cbfb Compare August 30, 2017 01:44

existentialism added the Tag: New Feature label Aug 30, 2017

Qantas94Heavy force-pushed the private-methods branch from d21cbfb to 6e7175d Compare August 30, 2017 02:55

littledan reviewed Aug 30, 2017

View reviewed changes

nicolo-ribaudo reviewed Aug 30, 2017

View reviewed changes

bakkot suggested changes Aug 31, 2017

View reviewed changes

jridgewell reviewed Sep 1, 2017

View reviewed changes

Qantas94Heavy force-pushed the private-methods branch from ce87518 to 5769ae5 Compare September 2, 2017 10:10

Qantas94Heavy force-pushed the private-methods branch from 339b4fb to 8645c96 Compare September 2, 2017 13:10

Qantas94Heavy force-pushed the private-methods branch 3 times, most recently from d5e0c38 to 8b5c2d5 Compare September 4, 2017 01:30

bakkot approved these changes Sep 4, 2017

View reviewed changes

jridgewell approved these changes Sep 6, 2017

View reviewed changes

jridgewell suggested changes Sep 6, 2017

View reviewed changes

Qantas94Heavy force-pushed the private-methods branch from 8b5c2d5 to 09c3f50 Compare September 6, 2017 02:44

Qantas94Heavy added 6 commits September 6, 2017 21:31

Add support for class private methods

c76ccd2

This commit adds parser support for the TC39 Stage 2 Private Methods proposal. This commit also changes "key" in ClassPrivateProperty from an Identifier to a PrivateName, as well as disallowing #constructor as a valid private field name.

Add tests for class private methods

e9232cd

This also removes a test from the Test262 whitelist that failed before the changes for private methods support and now passes.

Modify class private prop tests for PrivateName

15b1a5f

Add class private prop tests for #constructor

15ab4fd

Add tests for string literal get/set/async

2bc0cc4

These should be treated as regular methods and not special get/set/async behaviour.

Fix existing ASI test case failure

62233fb

Qantas94Heavy force-pushed the private-methods branch from 09c3f50 to 62233fb Compare September 6, 2017 11:32

jridgewell approved these changes Sep 6, 2017

View reviewed changes

littledan approved these changes Sep 6, 2017

View reviewed changes

jridgewell merged commit 65bea96 into babel:master Sep 6, 2017

hzoo mentioned this pull request Sep 28, 2017

Private Methods (and accessors) (Stage 3) babel/proposals#22

Open

marcofugaro mentioned this pull request Aug 16, 2018

class-private-methods aren't working in latest release babel/babel#8484

Closed

Add support for class private methods #703

Add support for class private methods #703

Conversation

Qantas94Heavy commented Aug 29, 2017 • edited Loading

jridgewell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Qantas94Heavy Aug 30, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

littledan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bakkot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Qantas94Heavy commented Sep 2, 2017 • edited Loading

bakkot commented Sep 2, 2017

Choose a reason for hiding this comment

jridgewell left a comment

Choose a reason for hiding this comment

Qantas94Heavy commented Sep 6, 2017

Qantas94Heavy commented Aug 29, 2017 •

edited

Loading

Qantas94Heavy Aug 30, 2017 •

edited

Loading

Qantas94Heavy commented Sep 2, 2017 •

edited

Loading