tunnelvisionlabs / antlr4ts

Optimized TypeScript target for ANTLR 4

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Prepend "this." on method calls?

mtriff opened this issue · comments

This is a bit of a followup to #424.

As mentioned on that issue, JavaScript/TypeScript requires this. to be appended to method calls, while other languages do not. Currently, methods in grammar predicates will not be called correctly unless the grammar itself uses the this.method() format. This prevents using the same grammars that have been written for all other ANTLR4 language targets with antlr4ts without modification. Has there been any consideration to prepending this. to method calls during compilation?

For example, when trying to compile the PL/SQL grammar from v4-grammars, I needed to prepend this. to all calls to superclass methods (in addition to manually adding the import of the superclass, as mentioned in #483).

Actions in grammars are target-language-specific. Special properties using the $ syntax would need to have the this. prefix added during code generation, but other calls would need to be written in the target language.

There was some talk of an embedded language that worked with multiple targets, but it didn't pan out for several reasons:

  • Most real-world grammars are used in the context of a larger system that already picked one target language
  • The generated listeners and visitors have made many grammar actions obsolete
  • For the rare cases that don't fall into either of the above, it would be difficult to provide an embedded language general enough to meet the needs of these without still requiring some amount of language-specific code

For the rare cases that don't fall into either of the above, it would be difficult to provide an embedded language general enough to meet the needs of these without still requiring some amount of language-specific code

What about https://haxe.org/ ? It can be compiled to different languages including C#, Java, JavaScript, Python, etc.

Also, I wouldn't say they are rare cases. There are quite many issues related to compilation across different runtimes on grammar repository. Thus such a language would be useful.

Based on the fact that the main targets are all in maintenance mode, it feels safe to close this one as wontfix based on #484 (comment).