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. jjb > > > > > jjb > > > >> > >> > > >> > jjb > >> > > > > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
