IDE support?

[Alex Russell]

On Sep 12, 2011, at 8:38 AM, Claus Reinke 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). Unless the type system
> is fairly advanced, type safety only expresses a thin veneer of
> invariants, but coverage is total, and automatic.

I'm sorry, but as much as I want a type system, the idea of a "thin veneer" that imposes an ongoing tax at *all* declaration and usage sites is really distasteful. JS should do better than Java and it's ilk have managed.

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

That's correct, and it's not "wrong". The trick here is to make sure that the folks who want to pay the tax can, while leaving others free to avoid it.

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

--
Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723