Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] JSDT JS parser, internal representation, type inference and all that jazz

Hi all,

I've been working on accommodation of the JSDT core to ES6, new esprima parser etc. Right now I'm working on restoring
so called "bindings" used for code assistance etc.

I will finish the job that I've started and will implement initial bindings resolver for single source but... I must admit
that in my opinion what we're doing at the moment is wrong.

* We're trying to reuse old dom model inherited from JDK which is not fully compliant with JS reality even after
 addition of ES6 specific constructs.

* This model is not very convenient for internal and especially external use.

* We have to convert this model to fro JSON/other AST formats.

* Integration with JS modules like esprima or Tern or anything alike is resource consuming, complex, opaque, error prone
 etc.


So, what is the right way in my opinion? The answer is to completely abandon or internal representation (ASTDom) model,
esprima parser and any other JS based tools like Tern and switch to using Google closure compiler infrastructure instead.

This approach has the following advantages:

* Closure compiler is fast

* It's written in Java and there are no problem with integration.

* It's a mature project with vast and VERY active community

* It has it's own perfect internal representation (IR) and it's possible to use just AST(rhino trees) if necessary
  https://github.com/google/closure-compiler/tree/master/src/com/google/javascript/rhino

* IR has great traversal infrastructure
  https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/NodeTraversal.java

* IR and a pluggable compiler allows to perform all tasks that we need. IR can be used for for outline
   view, symbol tables for code assist, search, navigation, auto completion, refactoring and so on.

* It has call graphs, type flow graphs, type inference out of the box.
  https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/TypeInference.java

* It has code validation, lint etc
  https://github.com/google/closure-compiler/tree/master/src/com/google/javascript/jscomp/lint

* It has code printer
  https://github.com/google/closure-compiler/blob/master/test/com/google/javascript/jscomp/CodePrinterTest.java

* It's possible to use it's IR to perform any other necessary tasks like more elaborate type analysis that TAJS does.



In conclusion, I believe JSDT should switch to Google closure compiler back-end as soon as it possible before it's too
late. It would allow to forget about almost all low-level problems and concentrate on implementing functionality that is
visible and is really necessary for JSDT users:

* Fast modern editor

* Elaborate code assistance

* Smart navigation

* Smart refactoring

* Integration of v8, node, npm, gulp, babel etc

* Debugging

* JSX support

* and so on, you name it


Thank you.


-- 
Eugene Melekhov



Back to the top