For features such as expansion help (e.g. when you type a dot after a parameter name inside a function), you still need static analysis.
But your point stands: JS IDEs can and should go beyond “edit-compile-debug” (which has become so mainstream that many people forget about languages such as Common Lisp and Smalltalk). On Sep 13, 2011, at 6:44 , Breton Slivka wrote: > Forgive me if this has already been talked about, but is it possible > that trying to improve static analysis of javascript is barking up the > wrong tree? I think a better approach is to write your IDE in > javascript and have it running inside a context that has access to the > running JS environment. Think about the precedents set by Smalltalk > and Self, and even Forth, with hints of this happening in the modern > browser "debugger" environments which now have some rudimentary code > completion features. > > A JS IDE should be a running environment that can reflect on changes > to the environment dynamically and "save" them back out to your source > files, via some diff like protocol which can be rather > straightforwardly implemented with proxies, akin to how a self program > was essentially an in memory image core dump. > > Having your IDE hooked up to a running JS context gets around a lot of > your problems with static analysis, including even dealing with > dynamic property access, dynamically constructed objects, prototype > chains and inheritences, and function name aliases. > -- Dr. Axel Rauschmayer [email protected] twitter.com/rauschma home: rauschma.de blog: 2ality.com _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
