mar9000 / ecmascript4mps Goto Github PK

Reference documents:

• https://tc39.github.io/proposal-class-fields
• https://tc39.github.io/proposal-private-methods
  https://2ality.com/2019/07/private-methods-accessors-in-classes.html
• https://tc39.es/proposal-decorators/#sec-syntax

Class fields implementation

• a migration transforms the JSIdentifier of JSMemberExpression in JSIdentifierName because reserved words are permitted as internal fields name like myObject.function.
  The migration has also an associated test.

• add JSPrivateIdentifier that extends JSIdentifierName:

  PrivateIdentifier::
    # IdentifierName

  It extends JSIdentifierName and has a different editor.

• add ClassElementName:

  ClassElementName[Yield, Await]:
    PropertyName[?Yield, ?Await]
    PrivateIdentifier

  It is an interface extended by JSIPropertyName and the new interface JSIPrivateIdentifier.

• add FieldDefinition:

  FieldDefinition[Yield, Await]:
    ClassElementName[?Yield, ?Await]   Initializer[In, ~Yield, ~Await]opt

  It's a concept, it implements the three interfaces to pass the parameters to the initializer.

• add an alternative to ClassElement:

  ClassElement[Yield, Await]:
    FieldDefinition[?Yield, ?Await];

  JSFieldDefinition implements the interface JSIClassElement.

• add an alternative to MemberExpression:

  MemberExpression[Yield, Await]:
    MemberExpression[?Yield, ?Await].PrivateIdentifier

  • MemberExpression alternatives have MemberExpression to the left, actually we have object: JSPrimaryExpression[1] so this os going to be changed in object: JSAbstractMemberExpression[1]. No migration required because we substitute with a subconcept.
  • on the right actually we can have JSIdentifier and it's not correct: the grammar has IdentifierName that allows also reserved words, infact myVar.for is permitted. A migration is required. We also need an interface grouping JSIIdentifierName and JSPrivateIdentifierReference, private identifier must be declared before used.

• private fields scope is implemented with:

  • JSClassDeclaration now implements ScopeProvider.
  • JSIClassElement extends JSBindingProvider so JSFieldDefinition can override the implementation.

• the following alternative to CallExpression is not needed:

  CallExpression[Yield, Await]:
    CallExpression[?Yield, ?Await].PrivateIdentifier

• tests:

  • for private fields scope.
  • for construction of this.#privateField.field.
  • for construction of this.field.field.

• examples for private fields and member expression of a member expression (this.a.a).

Private methods implementation

This implementation provides:

class MyClass {
  #privateOrdinaryMethod() {}
  // async, generator private methods will be implemented contextually to async, generator etc
  // * #privateGeneratorMethod() {}
  // set/get #privateGetSet() {}
}

The grammar is:

MethodDefinition[Yield, Await]:
  PropertyName[?Yield, ?Await](UniqueFormalParameters[~Yield, ~Await]){FunctionBody[~Yield, ~Await]}   <-- from
  ClassElementName[?Yield, ?Await](UniqueFormalParameters[~Yield, ~Await]){FunctionBody[~Yield, ~Await]}   <-- to

• change methodName : JSIPropertyName[1] to methodName : JSIClassElementName[1] in JSMethodDefinition, no migration required.

• let JSMethodDefinition overrides JSBindingProvider to provides scope for its private identifier if present.

Decorators implementation

This was already partially implemented. What we are missing is:

• for the alternative ( Expression[+In] ) of DecoratorMamberExpression I've added HasIn to JSParenExpressionDecorator.

• JSClassElement should extend JSIDecoratorList so methods and fields can be decorated (JSClassDeclaration is already this way).

• JSClassExpression should extend JSIDecoratorList, the concept is present but not yet used.

I just cloned and opened with MPS 2017.1 and it failed to migrate. I'm still new at using MPS. Is this project still active? Do you have plans to update it to work with the current version of MPS?

When a script is executed in the browser one needs functions from the global scope like setTimeout() or properties like document. With NodeJS the requirements are similar but with a different set of methods and properties.

The Window reference documentation is here.

Implementation

1. adding an environment child to JSProgram to point to one of the environment implementations to use in scope provider.

2. create a JSEnvironment concept to describe one or more environments.

3. JSEnvironment instances can extend one another to implement for instance:

   • a basic browser context plus extensions for specific browsers.
   • different context for different browser version.
   • different context for different NodeJS version.
   • Worker context are actually specified using a common inteface with the Window context.

4. create a devkit containing the language itself plus the solutions of the implemented environments.

The possibility to paste from plain text it's a feature and could be used while implementing new feature:

1. decide which java library to use for parsing javascript code, this will drive also the resulting AST that will be required to import into MPS.

We could leverage Travis CI to automatically run all tests and ensure that language and example solutions always build.