<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 17/02/2015 17:35, Gregory Szorc
wrote:<br>
</div>
<blockquote
cite="mid:CAJTgH0kGAMBcQtS0mVG3=pOG-q9nDWsnnZYuMTWGF8oWZ7AEiw@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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></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>
</div>
</div>
</blockquote>
There aren't clear style guidelines in browser JS. This is also not
really ES6/"custom SpiderMonkey stuff"-related, though. Unlike Mike,
I don't think losing most/all blame by reformatting all our source
is an "outdated" objection to changing that.<br>
<br>
I also don't think that purely a reformat will be sufficient to
unify style, we'd have to rename variables and s/var/let/ and such,
which is even more invasive (and will need significant amounts of
logic in the reformatter so as not to break stuff because of the
semantics changes). Or leave that out of the style guidelines, but I
don't see how that would then gain us much compared to the status
quo, if all that's "standardized" is whitespace, wrapping and brace
placement preferences.<br>
<br>
Either way, I think blame is a serious issue here.<br>
<blockquote
cite="mid:CAJTgH0kGAMBcQtS0mVG3=pOG-q9nDWsnnZYuMTWGF8oWZ7AEiw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
I can't think of much where I would really want to use this
besides... getting us off the old SpiderMonkey-specific patterns?
Which turns this into a bootstrap problem...<br>
<br>
I also suspect that our patterns of Cu.import and XPCOM usage (both
with string params) will not easily lend themselves to automatic
refactoring even if you solved the parsing problem.<br>
<blockquote
cite="mid:CAJTgH0kGAMBcQtS0mVG3=pOG-q9nDWsnnZYuMTWGF8oWZ7AEiw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
As noted, this needs interface descriptions for XPCOM and some
understanding of how Cu.import works (which will be tricky,
considering it relies on contents-of-string-arguments) if you want
anything in terms of completion. Not saying that wouldn't be worth
it, but it'd be tricky, even if we were ES3/5/6-compliant in terms
of syntax tomorrow.<br>
<blockquote
cite="mid:CAJTgH0kGAMBcQtS0mVG3=pOG-q9nDWsnnZYuMTWGF8oWZ7AEiw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</div>
</div>
</blockquote>
Right. So as Boris said, most of this just needs parsing and "glue"
to process the AST and hook up to our custom processing
scripts/specifications (for refactors/reformatting/linting).<br>
<br>
Do you have evidence that a significant number of the above problems
have ready-made "glue" that will work with ES6 once we get rid of
the SM-specific stuff? Because we already have a working parser and
AST generator - Reflect.parse. Its output format, last I checked, is
largely compatible with the existing toolset. The main problem was
ES6 stuff like "let", "const", "yield", generators, for...of, and
destructuring expressions. Ditching SM-specific things wouldn't
bridge that gap. Maybe I've been looking at the wrong tools, though?<br>
<br>
Separately, if we do need to do this, I guess I would expect that
writing such glue to refactor us out of SM-specific land into
vanilla-ES6-heaven would be more cost-effective (considering the
parser already exists!) than manually trying to do the same.<br>
<br>
~ Gijs<br>
</body>
</html>