waldron.rick at gmail.com
Mon Sep 12 12:19:29 PDT 2011
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
> 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
> 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.
> 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:
> 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
> 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
> of code behaviour one wants to preserve. Behaviour preservation is rarely
> absolute, and if one is happy with limited guarantees, automatic
> become possible. For instance, see
> for a discussion of some of the challenges involved in "simple"
> 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
>> much fun in this regard.
> Surprisingly difficult, see reference above. I believe jetbrains have some
> refactoring support:
> - 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.
> though approximations will be useful.
> Claus (who'd love to work on JS-in-JS tooling;-)
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss