On Mon, Sep 12, 2011 at 11:38 AM, Claus Reinke <[email protected]>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 > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
