Thanks Eugene for bringing this up.
I think we have several choices with inference, and probably the list
below does not cover all. Here is my quick thoughts.
1. Tern.js
tern.js is the most obvious choice for inference. It has the advantage
that it has
an existing community, it is familiar to Eclipse.org is it is used by
Orion. The boundary
crossings between JS/Java is an issue but I think we can probably
improve it switching our
JS runtime if we feel the need.
We also need to think about our integration strategy. We can try to
integrate tern.js output
directly into JSDT’s AST or use the same approach that tern.java has
which integrates on IDE
features level such as providing code completion implementations that
directly query tern and bypass
JSDT AST.
2. Implement own inference.
We can do this either with a project like TAJS or from scratch
ourselves(not preferred). However inference is
only half of the problem. We also need to have an efficient way to store
and query the information.
Per JSDT bugzilla, we already know that the borrowed JDT index/search
mechanism did not really work for JSDT.
I hear good things about the new indexer [1] but it needs to be tried
out in JS context.
I think combining TAJS with the new indexer could be a good experiment
to see the performance on large
projects.
Personally, I think what TAJS can do is really powerful and unique. I
think we can write a converter that can convert JSDT’s DOM AST to
one that TAJS can consume for a quick solution. I think it does make
sense to collaborate and see if we can come up with a solution
that scales and provides an integrated experience.
[1]
https://drive.google.com/file/d/0B-Bc97sHiy2lZmFPc210SXFDRU0/view?pref=2&pli=1
3. Another alternate is typescript language tools but technically it is
similar to tern.js with limitations.
I think with this option we have no way to avoid double parsing, and
looks like getting information that can be
incorporated to our AST is not possible.
—
Gorkem
On 31 Mar 2016, at 10:49, Eugene Melekhov wrote:
Hi all,
I've been thinking about missing code assist, search etc caused by
loosing type inference after switch to new parser.
First obvious candidate for type inference engine is widely used Tern
[1] of course. However using it has
some drawbacks like double parsing, JS->Java->JS data transfer etc. I
thought about writing something similar based on
Tern's idea, but reading some papers on the subject of JIT/static type
analysis I stumbled upon very interesting project
TAJS: Type Analyzer for JavaScript [2].
It has the Eclipse plugin and provides lot of useful type information.
It seems to be a great candidate for the JSDT's
inference engine. Even though it's possible to use it as is (just as
existing plugin) I believe both TAJS and JSDT may
benefit from more tight integration. I mean common AST for example.
TAJS uses the google closure compiler parser and thus its AST tree
format. We use esprima and convert it to our AST.
It's possible either come to some unified format or use google's or
use JSDT's.
I mentioned closure compiler parser some time ago, and its usage in
one more projects makes me think about it again.
So, what do you think about possible cooperation with TAJS to our
mutual benefit? :-)
[1] http://ternjs.net/
[2] http://www.brics.dk/TAJS/
--
Eugene Melekhov
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev