You are a gmail user, I surmise. So are others. Gmail collapses cited text, so you don't trim it. Those of us using other mail user agents then have to wade through *pages* of cited text to find your replies, which generally only apply to the last paragraph or two of the cited text.
Any googlers among you, please write a letter, or something. Gmail is training everyone to overcite massively. /be On Oct 5, 2011, at 3:11 PM, John J Barton wrote: > > > On Wed, Oct 5, 2011 at 2:25 PM, Russell Leggett <[email protected]> > wrote: > On Wed, Oct 5, 2011 at 1:18 PM, John J Barton > <[email protected]> wrote: > > > > > > On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett <[email protected]> > > wrote: > >> > >> 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. > > > > 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? > > Yes, because the analysis that aids development is not the same as the > analysis needed for JIT. > > 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. > > And I think we should keep the pressure on the JIT geniuses to continue to > deliver ever better performance without making developers add syntax, esp > when the additions are based on incomplete or version specific information. > > jjb > > > > > > jjb > > > > > >> > >> - Russ > > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
