[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: John Peberdy <john@xxxxxxxxxx>
- Date: Mon, 13 Aug 2012 14:36:49 -0400
- Delivered-to: email@example.com
On Mon, Aug 13, 2012 at 2:02 PM, Nitin Dahyabhai <nitind@xxxxxxxxxx> wrote:
> Answering in reverse order, Justin's reasoning for not running JS within
> VJET is pretty much why we don't do it in JSDT. It's fragile,
> unpredictable, and without a usable source DOM, only so useful.
I think there is a middle ground. You wouldn't want to execute certain
files and you wouldn't want to execute files while you're editing
them. So long as inter-file dependencies are explicit and it's
possible to modify the JS VM to limit side-effects and maintain
documentation nodes I think it is doable.
Existing JSDT functionality is necessary to support editing. It would
be faster and more tolerant of syntax errors. It would provide content
assist for known types.
> JSDT aims
> at fidelity with the available sources without extra metadata sprinkled
> into it just for JSDT's sake. Ideally, if you've already documented the
> sources so they're usable by other people working on the code, that should
> be enough information for JSDT (perhaps with the right plug-ins for that
> documentation format) to also use that for itself.
The trouble is I'm required to support content assist on richer
structures than JSDoc based tools supports. VJETDoc sounds like it
makes good compromises but I need to investigate more.
> As for AMD support, no, we haven't explored it in JSDT, nor been given
> contributions supporting it. IBM does have some support for it as used by
> Dojo in their Rational product line and the Websphere Developer Tools
> available out on the Marketplace, but my understanding is that it's
> limited to Dojo.
> Nitin Dahyabhai
> Eclipse WTP Source Editing and JSDT
> IBM Rational
> wtp-dev mailing list