ClassFields: Allowing comma separated grammar #608

diervo · 2017-07-02T00:01:14Z

Refactor for classFields:

Fixes Class Fields (combined) - Stage 2 #540
Fixes location for publicFields (should not contain semi-colon)
Allow decorators for comma separated fields
Added tests

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

jridgewell · 2017-07-02T00:27:40Z

src/parser/statement.js

+          this.state.inCommaSeparatedFields = true;
+          // Copy decorators for cases like `@foo x, y;`
+          if (decorators.length) {
+            member.decorators = decorators;


Let's slice here. It'll be really weird if a transform pushes a decorator and two fields get it.

jridgewell · 2017-07-02T00:30:54Z

src/parser/statement.js

@@ -899,7 +918,7 @@ export default class StatementParser extends ExpressionParser {
      }
    }

-    if (decorators.length) {
+    if (!this.state.inCommaSeparatedFields && decorators.length) {


I don't understand why inCommaSeparatedFields affects this. Maybe it should be a separate check instead (if fields can't have a trailing comma)?

jridgewell · 2017-07-02T00:35:09Z

src/parser/statement.js

@@ -1071,7 +1090,7 @@ export default class StatementParser extends ExpressionParser {
        /* isConstructor */ false,
      );
      this.checkGetterSetterParamCount(method);
-    } else if (this.isLineTerminator()) {
+    } else if (this.isLineTerminator() || this.match(tt.comma)) {


Does this mean methods can have trailing commas?

class Foo { method() { }, }

I don't see a test for it anywhere.

Will add more tests.

jridgewell · 2017-07-02T00:36:54Z

src/parser/statement.js

+
+      if (isClassField) {
+        if (this.eat(tt.comma)) {
+          this.state.inCommaSeparatedFields = true;


We can probably avoid this state entirely.

I don't think we can completely get away without knowing we are within the context of a coma separated production due to ASI and explicit checks for ;
Im revising it nonetheless.

nicolo-ribaudo · 2017-07-02T17:35:08Z

Fixes location for publicFields (should not contain semi-colon)

Why? Usually the semicolon is included:

var a = 2; // start: 0, end: 10

foo(); // start: 0, end: 6

diervo · 2017-07-02T18:09:15Z

@nicolo-ribaudo Not for comma separated statements, which is what I'm refering here.

import { a, b, c } from "x" // location do not include comma
var x = 1, b = 2, z = 3; // location do not include comma

Will revisit, and will try to to make it consistent, but it might be tricky.

- Fixes babel#540 - Allow decorators for comma separated fields - Added tests

diervo · 2017-07-02T23:22:33Z

Ok based on the comments I refactor pretty much the whole thing (sorry I had to rebase for simplicity of sake):

Added more tests
All locations should be correct now (@nicolo-ribaudo)
Refactor for better parse errors when we a re in the comma separated case.

@jridgewell We need to know whether or not we are in a "comma-separated" statement inside parseClassMember to check for specific unexpected characters depending on the case (method vs. prop)

nicolo-ribaudo · 2017-07-03T12:00:44Z

I have a doubt about decorators:

class A {
  @dec x, y;
}
class B {
  @dec x;
  y;
}
class C {
  @dec x;
  @dec y;
}

Is A more like B or like C? According to this pr, it is like C; Typescript interprets it like B.
The decorators2 plugin doesn't have this problem because it disallows decorators on class prpoerties, but we should decide how must decrators behave,

diervo · 2017-07-03T21:44:23Z

@nicolo-ribaudo

A and C are equivalent.
Decorators should be applied to all the comma separated fields (keep me honest @littledan)

@peey should revisit this logic once this PR lands in master.

littledan · 2017-07-04T11:50:00Z

@diervo Agree with what you're saying about equivalency (except it matters how many times dec is evaluated--imagine it's a getter on the global object, or inside a with). A decorator applying to multiple comma-separated elements is the entire reason comma-separated elements were proposed by @wycats; maybe he can provide more clarification.

Some test ideas:

Static fields that are comma-separated: class C { static x, y }
Invalid to put a comma between two methods class C { a(){}, b() {} }
Mixed public and private fields that are comma-separated class C { #x, y }

cc @bakkot

nicolo-ribaudo · 2017-07-04T13:50:57Z

except it matters how many times dec is evaluated

Then the AST must somehow reflect the difference between a decorator applied to a list of properties and the same decorator applied to different properties. Otherwise how could babel-generator/prettier/any other code generator know what code to emit?

e.g.

AST

Program {
  body: [
    ClassDeclaration {
      id: Identifier { name: "Foo" },
      body: ClassBody {
        body: [
          ClassProperty {
            decorators: [
              Decorator {
                expression: CallExpression {
                  callee: Identifier { name: "dec" },
                  arguments: []
                }
              }
            ],
            key: Identifier { name: "a" }
          },
          ClassProperty {
            decorators: [
              Decorator {
                expression: CallExpression {
                  callee: Identifier { name: "dec" },
                  arguments: []
                }
              }
            ],
            key: Identifier { name: "b" }
          }
        ],
      },
    },
    FunctionDeclaration {
      params: [],
      body: BlockStatement {
        body: [
          "dec = () => { throw new Error(); }",
          "return /* super cool decorator */"
        ]
      }
    }
  ]
}

This ast represents to different programs: one works and the other throws.

class Foo {
  @dec() a, b; // works
}

function dec() {
  dec = () => { throw new Error(); };
  return decorator;
}

class Foo {
  @dec() a;
  @dec() b; // Throws
}

function dec() {
  dec = () => { throw new Error(); };
  return decorator;
}

A possible solution is to represent a comma-separated list of properties actually as a list of properties, similar to a VariableDeclaration:

class Foo {
  @dec() a, b;
}

AST

ClassDeclaration {
  id: Identifier { name: "Foo" },
  body: ClassBody {
    body: [
      ClassPropertiesList {
        decorators: [
          Decorator {
            expression: CallExpression {
              callee: Identifier { name: "dec" },
              arguments: []
            }
          }
        ],
        static: false,
        properties: [
          ClassProperty {
            key: Identifier { name: "a" }
          },
          ClassProperty {
            key: Identifier { name: "b" }
          }
        ],
      }
    ],
  },
}

This approach has other two possible little advantages:

It prevents the inconsistent locations due to the commas and semicolons: ClassPropertiesList would contain the semicolon, which for now is included in the last property.
The location of the decorators nodes will be included in the parent node (currently, the decorators are child of every property in the list but the location of the property does not include the decorators')

I'm sorry if I may sound quite pedantic, but I'm trying to highlight possible problems 😶

diervo · 2017-07-04T15:28:36Z

@littledan @nicolo-ribaudo I think you are both right, but this will require some interesting refactor, and probably a somewhat big breaking change on the transformers for publicFields.

Is everyone ok then moving to the following productions (analogous to VariableDeclaration):

FieldDefinition:
+decorators: []
+definitions: [PublicField | PrivateField]

Basically any public/private fields will be enclosed by FieldDefinition, and no more decorators in the Fields itself.

If we do this, we might as well refactor the whole ClassBody to make it future proof as @jridgewell was suggested to do in #609.

If you give me thumbs up I can give it a run today, otherwise will have to wait til next weekend most likely or someone else can take over.

Thoughts?

nicolo-ribaudo · 2017-07-04T15:37:47Z

and probably a somewhat big breaking change

In #609 @xtuc suggested to merge the classProperties and classPrivateProperties. We can enable the changes introduced by this pr only under the new plugin to avoid breaking changes

diervo · 2017-07-04T16:00:03Z

@nicolo-ribaudo The problem is not creating a new plugin, is the fact that we are changing the shape of the Nodes (for example no longer ClassProperty will have decorators, or potentially a change on the node name ClassProperty =>PublicField ) that transformers expect.

And I'm very reluctant to have a fork in the code that generate different Node types based on the syntax plugin that is enabled, specially since we are working in babel7 where we have more room for error. If we do this changes, my vote is to do it in a non backward compatibility way.

@hzoo what you think?

littledan · 2017-07-04T17:00:19Z

If this is for Babel 7, could the legacy decorator syntax and transform also be updated to the new AST as well? It seems like the new form you're proposing is simply more general. Are there a lot of transforms out there which depend on the current shape of decorators?

diervo · 2017-08-13T01:48:24Z

Closing this since comma separated proposal was dropped from the original classField proposal and will be advancing separately.

littledan · 2017-08-15T13:31:23Z

If someone wants to reopen the PR and pick it up, you can find the new proposal at https://github.com/littledan/proposal-comma-separated-fields . The default class fields flag needs to prohibit comma separation, with a separate flag to permit it; I am not sure whether this flag behavior should be implemented at the babylon or transform level.

jridgewell suggested changes Jul 2, 2017

View reviewed changes

hzoo added Spec: Class Fields spec-update Tag: New Feature labels Jul 2, 2017

Refactor for classFields:

8dcb23b

- Fixes babel#540 - Allow decorators for comma separated fields - Added tests

diervo force-pushed the privateFieldsFixes branch from 113ea5a to 8dcb23b Compare July 2, 2017 23:15

Fixing misspelling json test

d090211

diervo mentioned this pull request Jul 3, 2017

Add static private class field support #609

Merged

littledan mentioned this pull request Jul 14, 2017

Remove comma-separated field declaration syntax from this proposal tc39/proposal-class-fields#20

Closed

diervo closed this Aug 13, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ClassFields: Allowing comma separated grammar #608

ClassFields: Allowing comma separated grammar #608

diervo commented Jul 2, 2017 •

edited

Loading

jridgewell Jul 2, 2017

diervo Jul 2, 2017

jridgewell Jul 2, 2017

jridgewell Jul 2, 2017

diervo Jul 2, 2017

jridgewell Jul 2, 2017

diervo Jul 2, 2017 •

edited

Loading

nicolo-ribaudo commented Jul 2, 2017

diervo commented Jul 2, 2017 •

edited

Loading

diervo commented Jul 2, 2017 •

edited

Loading

nicolo-ribaudo commented Jul 3, 2017

diervo commented Jul 3, 2017 •

edited

Loading

littledan commented Jul 4, 2017

nicolo-ribaudo commented Jul 4, 2017 •

edited

Loading

diervo commented Jul 4, 2017 •

edited

Loading

nicolo-ribaudo commented Jul 4, 2017

diervo commented Jul 4, 2017 •

edited

Loading

littledan commented Jul 4, 2017

diervo commented Aug 13, 2017

littledan commented Aug 15, 2017

ClassFields: Allowing comma separated grammar #608

ClassFields: Allowing comma separated grammar #608

Conversation

diervo commented Jul 2, 2017 • edited Loading

jridgewell Jul 2, 2017

Choose a reason for hiding this comment

diervo Jul 2, 2017

Choose a reason for hiding this comment

jridgewell Jul 2, 2017

Choose a reason for hiding this comment

jridgewell Jul 2, 2017

Choose a reason for hiding this comment

diervo Jul 2, 2017

Choose a reason for hiding this comment

jridgewell Jul 2, 2017

Choose a reason for hiding this comment

diervo Jul 2, 2017 • edited Loading

Choose a reason for hiding this comment

nicolo-ribaudo commented Jul 2, 2017

diervo commented Jul 2, 2017 • edited Loading

diervo commented Jul 2, 2017 • edited Loading

nicolo-ribaudo commented Jul 3, 2017

diervo commented Jul 3, 2017 • edited Loading

littledan commented Jul 4, 2017

nicolo-ribaudo commented Jul 4, 2017 • edited Loading

diervo commented Jul 4, 2017 • edited Loading

nicolo-ribaudo commented Jul 4, 2017

diervo commented Jul 4, 2017 • edited Loading

littledan commented Jul 4, 2017

diervo commented Aug 13, 2017

littledan commented Aug 15, 2017

diervo commented Jul 2, 2017 •

edited

Loading

diervo Jul 2, 2017 •

edited

Loading

diervo commented Jul 2, 2017 •

edited

Loading

diervo commented Jul 2, 2017 •

edited

Loading

diervo commented Jul 3, 2017 •

edited

Loading

nicolo-ribaudo commented Jul 4, 2017 •

edited

Loading

diervo commented Jul 4, 2017 •

edited

Loading

diervo commented Jul 4, 2017 •

edited

Loading