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

Hi John,

see comments intermixed

On Mon, Aug 13, 2012 at 12:14 PM, John Peberdy <john@xxxxxxxxxx> wrote:
> VJET looks very interesting.
>
> VJET includes an object system library, VJO. Are types defined using
> this library available to content assist?

Yes types defined are all available to content assist. There are typed
object literals, functions, classes, enum, mixins, interfaces, etc.

Behind the scenes they populate the JstType object. You can see what
the model looks behind the scenes using the ScriptUnit view.


Are they available through
> special handling of the calls to VJO functions, or does VJETDoc
> support defining these structures with tags?

I am not exactly sure what you mean by support the structures with
tags? Are you referring to jsdoc annotations such as @class?

 If I understand correctly
> VJET does not execute code to provide content assist for these
> objects, right?

Yes this is correct. We use type libraries to provide rich code
assist. VJET also does infrencing and provides good assist when the
type is known and when the type is not known it will degrade to Object
which is treated as a dynamic object.  The types can be created by
executing the JS code and creating the initial type library such as
identifying the global vars, types, prototype (methods, properties).
The challenge is for how the runtime can provide correct assist and
support correct semantics such as variant type, variable arguments or
mixed types. Variant type means that a method/function can take more
than one type and mixed types means that the resulting type would be a
mixture of the input.

>
> On Mon, Aug 13, 2012 at 12:14 PM, Justin Early <earlyster@xxxxxxxxx> wrote:
>> Hi John,
>>
>> I know you are asking about JSDT but I would like to take this opportunity
>> to discuss an alternative project VJET which builds on the JSDT project and
>> provides rich assist for nodejs modules.
>>
>> #1...
>>
>> The VJET JS Toolkit has done some work with nodejs modules not AMD but the
>> pattern is similar to provide code assistance and validation. For more info
>> about VJET JS Toolkit see
>> https://www.ebayopensource.org/index.php/VJET/HomePage and for more info
>> about VJET moving to webtools please see the project proposal -
>> http://www.eclipse.org/proposals/webtools.vjet/. To see what was done for
>> nodejs modules you can see this page for some examples -
>> https://www.ebayopensource.org/index.php/VJET/NodeJS
>>
>> #2...
>>
>> VJET avoids execution during authoring of JS code. You can execute the code
>> and then generate a type library which has all the information needed for
>> code assist and validation. Only static analysis is done using a recovery
>> based AST parser. The structure of the JS code is only available when the
>> code has no syntax errors. Also another reason that running the code is not
>> viable is that there may be runtime errors due to dependency order issue. I
>> know that AMD does solve some of these dependency order issues so it is
>> possible but this will just help with name assist. In order to get the type
>> info you need the jsdoc or type hints such as function arguments which
>> construct a type or define a type. Running the authored js also causes high
>> CPU which ends up running the fan on some notebook computers.
>>
>> Justin
>>
>> On Aug 11, 2012, at 10:49 PM, John Peberdy <john@xxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> I'm evaluating implementing functionality for JSDT and looking for feedback.
>>
>> What I need to do is support content assist for AMD style code and
>> code that is otherwise not straight forward to analyze (for example
>> calling a function to create a new subclass).
>>
>> 1. Has any work been done to add support for AMD style modules (or
>> other module systems)?
>>
>> 2. Instead of inferring the structure of the objects and functions
>> that a file defines manually, what are your thoughts on executing the
>> JavaScript of the file and examining the result? This will give the
>> exact structure of what the file defines (with some caveats, eg no
>> DOM, side effects would have to be limited). Then we'd have to
>> correlate JSDoc nodes to nodes in the evaluation result.
>>
>> Thanks for any feedback.
>>
>> Regards
>> John
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>
>>
>>
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>
>
>
>
> --
> John Peberdy
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev