About not changing the behavior for chrome JS, the prospect of having chrome JS
becoming more divergent from standard JS is unwelcome to me. Having additional,
orthogonal features is one thing, but a fundamental feature with the same
syntax that behaves differently depending on the context is very unsavory.
----- Original Message -----
From: "Ehsan Akhgari" <ehsan.akhg...@gmail.com>
To: "Shu-yu Guo" <s...@mozilla.com>, dev-platform@lists.mozilla.org,
dev-g...@lists.mozilla.org
Cc: "Jorge Villalobos" <jo...@mozilla.com>
Sent: Wednesday, August 13, 2014 2:45:17 PM
Subject: Re: Non-backward compatible changes to JS 'let' semantics
AFAICT gaia doesn't use let in its core code (since let is not available
in non-chrome js yet) but it does use it in its build scripts etc.
However, let is pretty heavily used in add-ons. CCing Jorge who can
probably help with what to do with that. But have we considered not
changing the behavior for chrome JS?
Cheers,
Ehsan
On 2014-08-13, 5:29 PM, Shu-yu Guo wrote:
> Hello all,
>
> We are in the process of making JS 'let' semantics ES6-compliant in
> SpiderMonkey. I hope to land bug 1001090 sometime this month or early next
> month (I've been told there's a B2G uplift on Sept 1st), which is one of many
> for ES6 'let'-compliance. It changes 'let' semantics in two non-backward
> compatible ways:
>
> 1. 'let' bindings may no longer redeclare existing bindings in function
> scope. (In ES6, this is also true for global code, but global 'let'
> changes are distinct from bug 1001090 and will be addressed by bug
> 589199.)
>
> Currently, 'let' bindings at the function body-level are semantically
> equivalent to 'var' bindings. This means that the following JS are
> legal:
>
> function f(x) { let x = x || ""; }
> function g() { let x = 42; let x = 43; }
>
> When bug 1001090 lands, these will be syntax errors.
>
> 2. 'let' bindings may not be accessed in any fashion before initialization.
> Initialization means execution of the |let x| or |let x = rhs|
> forms. Before initialization, the 'let' bindings are in a "temporal dead
> zone" (TDZ). The TDZ is enforced dynamically, throwing a ReferenceError.
>
> When bug 1001090 lands, the following JS throw:
>
> function f() { x = 42; let x; }
> function g() { function inner() { x = 42; } inner(); let x; }
> function h() { switch (c) { case 0: let x; break; default: x = 42;
> break; } }
>
> These changes wreak havoc on our existing chrome JS, largely due to item 1
> above. It will be a rough landing, so I am raising awareness of these breaking
> changes now. The changes will likely initially land under a Nightly-only
> #ifdef.
>
> I can fix (or can find someone to fix) code that is in mozilla-central. But
> code that is outside of that tree will be problematic. Namely, Gaia and
> addons.
> Can someone own updating Gaia JS to be ES6-compliant? It is unclear to me what
> should be done about addons.
>
> The takeaway for developers is to refrain from using the patterns I've listed
> above starting now in any new code, before bug 1001090 lands. The patterns in
> item 2 above are bad form and should never have been used, but those from item
> 1 have seen a fair bit of use.
>
> P.S. I am not subscribed to dev-gaia. For those on that list but not on
> dev-platform, please reply to me at my email address.
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
