IDE support?

[Claus Reinke]

>> 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). 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

DoctorJS's <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/

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

> - 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/