Lexer: Backticks should allow adding code to class body

[wcjohnson]

ES2015 spc allows method definitions to be prefixed by get or set in which case they are transformed to property getters and setters.

Of the following, only A generates the corresponding ES2015 output:

class A
	x: -> 42

class B
	get x: -> 42

class C
	`get` x: -> 42

class D
	`get x`: -> 42

class E
	`get x() { return 42; }`

B makes a hoisted class body (as expected), C and D are syntax errors, and E, which would seem like it should be the ultimate escape valve, generates a hoisted class body as well.

It would be nice to have some kind of escape valve for modifying the definitions within the non-hoisted portion of ES2015 class body. It would be particularly nice if backticks could be made to serve this function, as they can help support other possible future syntax (e.g. decorators) as well.

[GeoffreyBooth]

@connec

See also coffeescript6/discuss#17

[connec]

Recommended escape valve atm would be to use Object.defineProperty.

class A
  Object.defineProperty @prototype, 'x', get: -> 42

[wcjohnson]

After reading that other thread I understand all the objections to mucking around with syntax, and yeah, just going back to ES5 works (though now I'm doing the job my transpiler is supposed to do for me!)

However, I would think that on general principle, there should be some backtick-esque escape valve for getting stuff inside of the inner class body.

[GeoffreyBooth]

Perhaps this issue should be more about “backticks should allow inserting code into class body” or whatever you call the area that’s not the executable class body? And we can keep the other issue for discussing adding support for getters/setters.

[wcjohnson]

If done right, you could probably kill both birds with one stone. If my example C wasn't a syntax error, but instead caused the backticked code to be directly inserted into the class body, you would have solved both getters and decorators.

I think it might also bypass the grammar ambiguities referenced int he other thread too, but I am not familiar with the CS lexer so I could be wrong about that.

[GeoffreyBooth]

Well we never want to require people to use backticks. We went through the trouble of adding support for import/export primarily to avoid that.

Decorators is an unusual case as the spec isn’t finalized yet, and it’s our policy not to support unfinalized specs. So backtick support for what you’re talking about would be a good thing to have, so that people can use decorators until the spec is finalized and then we add native support for them.

[wcjohnson]

I think if it could be made to work, it would be a winning move on the whole, even if you went on to add a full syntax for getters and setters later.

• It obeys the semantic intent of backticks, which is a "just insert this raw code here" escape valve.
• It gives you getters and setters with a syntax that looks pretty much like you'd expect, maybe something like what the integrated syntax looks like later. (Although the grammar ambiguities mentioned in the other thread look bad for the integrated syntax.)
• It lets you escape out to other future JS features that involve different syntax in the class body -- decorators, etc.