On Wed, Oct 5, 2011 at 11:49 AM, John J Barton <[email protected]> wrote: > > > On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett <[email protected]> > wrote: >> >> On Wed, Oct 5, 2011 at 10:52 AM, John J Barton >> <[email protected]> wrote: >> > >> > >> > On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett >> > <[email protected]> >> > wrote: >> >> >> >> On Wed, Oct 5, 2011 at 10:32 AM, John J Barton >> >> <[email protected]> wrote: >> >> > >> >> > >> >> > On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <[email protected]> >> >> > wrote: >> >> >> >> >> >> 2011/10/4 Russell Leggett <[email protected]>: >> >> >> > On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel >> >> >> > <[email protected]> >> >> >> > wrote: >> >> >> > >> >> >> >> No it doesn't. >> >> >> >> >> >> >> >> Just walk the object graph starting from the root object and let >> >> >> >> the >> >> >> >> set of all reachable symbols be A. >> >> >> >> Load jQuery >> >> >> >> Walk the object graph again letting the set of all reachable >> >> >> >> symbols >> >> >> >> be >> >> >> >> B. >> >> >> >> >> >> >> >> The public API of jQuery is then (B - A). >> >> >> > >> >> >> > That's works fine under 2 conditions: >> >> >> > >> >> >> > 1. You're willing to execute code instead of statically analyze it >> >> >> > 2. You're capable of executing that code in isolation. >> >> >> >> >> >> This should be true for most libraries out there. >> >> >> It obviously doesn't hold for user code and definitely not for all >> >> >> code in an IDE since IDE's have to deal with code during editing. >> >> > >> >> > I'm not a jQuery person, but as far as I can tell jQuery introduces >> >> > only >> >> > one >> >> > global value so the jQuery API is just the properties of that object >> >> > at >> >> > the >> >> > point in the program where the developer needs to use jQuery. You >> >> > don't >> >> > have to execute code and the only graph you need to walk is the >> >> > properties >> >> > of one object. >> >> >> >> If you looked at the code for more than 5 minutes, you'd see that the >> >> jQuery codebase, while interesting to look at, would be ridiculously >> >> hard to statically analyze without understanding jQuery conventions. >> >> The bulk of the methods are added through calls to 'jQuery.extend(...' >> >> and 'jQuery.fn.extend(...' >> >> >> > >> > Sure, that's the way lots of JS code works, which is why I think IDEs >> > based >> > on static analysis are doomed. >> >> I was responding to: >> >> >> > You don't have to execute code and the only graph you need to walk is >> >> > the >> >> > properties of one object. >> >> If you don't execute code, that's what static analysis is. I'm sorry, >> I must be missing something. And the way that jQuery (and any JS code >> that use a function of some kind to make classes) builds up its api is >> to use some helper methods, beyond which, static analysis has a really >> rough time. You don't seem to be disagreeing with me. > > Oh I got burnt by "static analysis" before, I should know better. I keep > thinking that static analysis means "analysis of a single compilation unit > outside of the runtime" as most IDEs for statically typed languages use. > > I meant: if your tool is embedded in the run time then it knows the exact > jQuery API because it can scan the exact jQuery object. No code on this > jQuery object needs to run (though that issue is not a show stopper in > practice, witness breakpoint debugging). > > I don't know what to call runtime analysis that does not run extraneous > code.
I see, yes. Yeah, I mean if I run the JavaScript console in chrome I get nice autocompletion because its using the running environment to know what properties an object has. I believe this is what a lot of smalltalk IDEs used to do. There are still a lot of limitations, though. I mean, what is the purpose of the analysis in the long run. Modern Java IDEs can do a lot of things with static analysis that are very helpful like refactoring and autocompletion. Look, I'm not trying to turn this into a static vs. dynamic debate, my point is that there are a lot of limitations - and useful tooling that is impossible with dynamic code. I think we got here because someone was trying to make the point that the ability to add statically analyzable constraints would be useful to tooling. In JavaScript, the way to do that may have to be through syntactic additions such as extends or <|. I'm certainly not opposed to analysis that goes beyond ASTs. I say, any way you can get it! - Russ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
