<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 17, 2015 at 7:40 AM, Boris Zbarsky <span dir="ltr"><<a href="mailto:bzbarsky@mit.edu" target="_blank">bzbarsky@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2/17/15 10:36 AM, Gijs Kruitbosch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, you would be surprised how much JS tooling assumes that<br>
references to |window| or |document| (or window's other properties!) are<br>
always valid<br>
</blockquote>
<br></span>
This tooling is already broken for workers, node.js, etc, right?  Can we not avoid such broken tooling and use tooling that doesn't make broken assumptions about the host environment?<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
or where (in order to get good/reasonable<br>
results for inferences and so on) we would need to provide descriptions<br>
of (web/xp)idl interfaces in some way that they can grok, as we can't<br>
always point to a JS implementation instead...<br>
</blockquote>
<br></span>
That's fair.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe we have very different expectations of what "tooling" means here -<br>
</blockquote>
<br></span>
That's possible.  Gregory's post was very light on specifics...<span><font color="#888888"></font></span></blockquote><div><br></div><div>Here's a partial list:<br><br></div><div>* Machines should tell you when code doesn't conform to style guidelines<br></div><div>* Machines should be able to automatically reformat code to conform to style guidelines<br></div><div>* We should be able to mass-rewrite code by writing scripts that transform existing code (this is how Google and Facebook perform large refactors)<br></div><div>* Developers should be able to see code coverage for tests, etc (I view this as blocked on SpiderMonkey lacking a built-in high-performance tracing/profiling mechanism)<br></div><div>* Code editors and IDEs with JavaScript support should "just work"<br></div><div>* We should be able to write custom "linter" rules looking for common issues with Mozilla code (e.g. usage of nsIFile over OS.File)<br><br></div><div>A common theme in these is that machines should do more work for humans. I don't want people wasting time looking at things like code formatting during code review when they could be looking at something more important, such as what the code actually does.<br></div></div></div></div>