Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Type analisys for JSDT


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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev


Back to the top