IDE support?

[Rick Waldron]

On Mon, Sep 12, 2011 at 11:38 AM, Claus Reinke <claus.reinke at talk21.com>wrote:

>  I'm hopeful that type inference combined with class syntax and
>>> an (eventual) traits system will get us "there", so that you can use
>>> structural type tests for enforcement and that the IDE can get the
>>> benefit of hints through inference.
>>>
>>
> Improved, statically checkable, types would also help mitigate
> Javascript's silent failures (silently breaking code when trying to
> refactor, fixing bugs, or adding features).



Unit tests with comprehensive and thorough code coverage does this today.








> Unless the type system
> is fairly advanced, type safety only expresses a thin veneer of
> invariants, but coverage is total, and automatic. Together with
> static scoping, that tends to avoid a good deal of accidental
> changes that might go unnoticed when coding in current
> Javascript.
>
> As the Erlang folks discovered several times, retrofitting a useful type
> system onto a language whose code patterns evolved in a weak type
> system is hard. It isn't too difficult to come up with a type system that
> gives some info, but my personal impression was that coding styles
> have to adapt before the benefits of type inference can be reaped.
>
> There are some half dozen or more papers on Javascript type inference
> or static analysis (hmm, is there a central wiki or bibliography where
> we could record and collect such JS-related references? should I post
> here what I've found so far?).
>
> On the practical side, I seem to recall that Netbeans tried using type
> inference to help JS completion. Probably from this post:
>
> http://blogs.oracle.com/tor/**entry/javascript_type_**inference<http://blogs.oracle.com/tor/entry/javascript_type_inference>
>
> DoctorJS's <https://github.com/mozilla/**doctorjs<https://github.com/mozilla/doctorjs>>
> analysis has
> also been used to provide code completion for some projects.
> That seems to have been put on the backburner during the recent
> cloud editor convergence.
>
>
>  That said, I think the "I want to refactor automatically" use-case is
>>> sort of over-played.
>>>
>>
> That depends. Automatic "refactoring", in the strict sense of changing
> code structure without changing code behaviour, is nearly impossible
> for Javascript, as there are hardly any valid code equivalences (none if
> you count reflection).
>
> That still leaves the wide area of automated code transformations: just
> as we like to have libraries to query and transform the DOM, many of
> us like to have support for querying and transforming source (or at
> least ASTs). This kind of language-aware grep/sed would be automated,
> but not automatic (the results would need to be verified).
>
> That said, part of defining refactorings is to be explicit about what
> aspects
> of code behaviour one wants to preserve. Behaviour preservation is rarely
> absolute, and if one is happy with limited guarantees, automatic
> refactorings
> become possible. For instance, see
>
>   Tool-supported Refactoring for JavaScript
>   http://cs.au.dk/~amoeller/**papers/jsrefactor/<http://cs.au.dk/~amoeller/papers/jsrefactor/>
>
> for a discussion of some of the challenges involved in "simple"
> refactorings.
>
>
>  Indeed. The type-system related features I use most often in Eclipse are:
>> - *Safely* renaming a method or function. I do this frequently to keep the
>> vocabulary used in methods etc. fresh. All JS IDEs that I have tried are
>> not
>> much fun in this regard.
>>
>
> Surprisingly difficult, see reference above. I believe jetbrains have some
> JS
> refactoring support:
>
> http://www.jetbrains.com/**editors/javascript_editor.jsp?**ide=idea#js<http://www.jetbrains.com/editors/javascript_editor.jsp?ide=idea#js>
>
>
>  - Jump to the definition of a method/function.
>>
>
> Not too difficult for functions (modulo complex, statically undecidable
> import/export patterns), though you do need a parser and proper scope
> tracking - try DoctorJS (uses Narcissus) for tags file generation.
>
> It used to track object properties better (which was used for navigation
> and completion), but apparently that got broken a while ago. This is the
> part that would improve completion and navigation to methods or
> module exports.
>
> I'm in the process of adding scoped tags support to DoctorJS, so that
> in Vim you can also navigate to local definitions and parameters (in
> principle, that would also give access to any local information produced
> by DoctorJS's analysis, but I'm not sure whether that information is
> recorded anywhere). Generation and navigation already works, I just
> have to push to github, figure out pull requests and submodules, and
> write a blog post to explain the whole thing..
>
>
>  - Find all invocations of a method/function. Often, I just change the
>> name of a method (e.g. by appending an "x") and go through all the
>> errors that that produces.
>>
>
> Again, that is undecidable in general, due to Javascript's flexibility,
> though approximations will be useful.
>
> Claus (who'd love to work on JS-in-JS tooling;-)
> http://clausreinke.github.com/
>
>
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110912/7f1733cd/attachment.html>