On Wed, Oct 5, 2011 at 1:18 PM, John J Barton <johnjbar...@johnjbarton.com> wrote: > > > On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett <russell.legg...@gmail.com> > wrote: >> >> On Wed, Oct 5, 2011 at 11:49 AM, John J Barton >> <johnjbar...@johnjbarton.com> wrote: >> > >> > >> > On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett >> > <russell.legg...@gmail.com> >> > wrote: >> >> >> >> On Wed, Oct 5, 2011 at 10:52 AM, John J Barton >> >> <johnjbar...@johnjbarton.com> wrote: >> >> > >> >> > >> >> > On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett >> >> > <russell.legg...@gmail.com> >> >> > wrote: >> >> >> >> >> >> On Wed, Oct 5, 2011 at 10:32 AM, John J Barton >> >> >> <johnjbar...@johnjbarton.com> wrote: >> >> >> > >> >> >> > >> >> >> > On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel >> >> >> > <mikesam...@gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> 2011/10/4 Russell Leggett <russell.legg...@gmail.com>: >> >> >> >> > On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel >> >> >> >> > <mikesam...@gmail.com> >> >> >> >> > 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. > > And it is on this exact point that we disagree.... >> >> 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! > > ... because once we go beyond ASTs much of the value of changing the > language for tools goes away. > > Of course if you make developers do more work for tools, tools can be > better. But we should first ensure that tools do their best, then decide > what to force on devs.
Sometimes going beyond ASTs is extremely challenging - but OK, let's just say we reach a point where we have tools good enough that they can read in code that has been run through a build tool so that they can actually evaluate an entire code base as it would be delivered to the browser. Now what? Do you think that any tool will do a better job of runtime analysis than the tracing JITs that browsers have now? The whole goal for advanced JavaScript compilers is to be able to take a JavaScript program which is incredibly mutable and unconstrained, and pin down what the constraints actually are to generate better code. These constraints are what we're talking about, the ability to make certain guarantees. In the case of JavaScript, some of those guarantees are hard to make, whether statically, or at runtime. Additional syntax is a way of adding certain guarantees and I am not entirely opposed to that. That doesn't mean I want to throw everything including the kitchen sink in. > > jjb > > >> >> - Russ > > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
