It would probably be easy for them to fix, yes. But we have a roughly fixed
amount of capital with addon authors with which to force them to make
compatibility fixes - at some point, some number of them get fed up and
stop updating their code. I'm really not sure that this is a worthy place
to spend it.
+1 to Bill's idea.
On Thu, Sep 18, 2014 at 9:47 AM, Philipp Kewisch <mozi...@kewis.ch> wrote:
> Is the AMO compatibility checker powerful enough to detect at least the
> first category of required changes? If so I don't think we should make
> any more special cases than needed.
>
> While the change is annoying for addon authors, in most cases the
> redeclaration is just an oversight and it would improve style to fix it.
>
> Philipp
>
>
> On 9/18/14 4:51 AM, Bill McCloskey wrote:
> > If this change proves to be really disruptive to add-on authors, I
> wonder if we could just make "let" behave like "var" for add-ons? The JS
> tokenizer could just substitute var for let when parsing code from an
> add-on compartment. (Bug 1030420 will put add-on code in a separate
> compartment and it's ready to land soon.) I think that would mostly
> mitigate the concerns Jeff raised in the previous thread about having to
> test two configurations.
> >
> > -Bill
> >
> > ----- Original Message -----
> >> From: "Shu-yu Guo" <s...@mozilla.com>
> >> To: "Chris Peterson" <cpeter...@mozilla.com>
> >> Cc: dev-platform@lists.mozilla.org
> >> Sent: Wednesday, September 17, 2014 5:26:57 PM
> >> Subject: Re: ES6 lexical temporal dead zone has landed on central
> >>
> >> Well, SM's 'let' extension never really let you redeclare let bindings.
> What
> >> happened was that it was too much work to parse function body-level
> lets as
> >> actual lets, and so they were parsed as vars, thus allowing
> >> "redeclarations".
> >>
> >> Keep in mind that vars aren't *really* redeclared. When actual
> semantics is
> >> closer to erasure semantics: just pretend the second var isn't there.
> That
> >> is, consider
> >>
> >> var x = 42;
> >> var f = function () { print(x); }
> >> var x = 43;
> >> var g = function () { print(x); }
> >>
> >> f and g above are closing over the *same* binding of x.
> >>
> >> I would bet that Rust lets you actually redeclare (viz. shadow with a
> new
> >> binding in the same scope) , such that if you had the equivalent code in
> >> Rust above, f and g would close over *different* bindings.
> >>
> >> So having lets behave like vars in that respect is probably going to
> lead to
> >> the same crappiness that we have with vars now. Why they didn't allow
> >> shadowing with a new binding? I don't know, it would be nice -- but
> perhaps
> >> was too big a break, and that it would behave strangely, or at least
> >> surprisingly, with hoisting semantics.
> >>
> >> ----- Original Message -----
> >> From: "Chris Peterson" <cpeter...@mozilla.com>
> >> To: dev-platform@lists.mozilla.org
> >> Sent: Wednesday, September 17, 2014 4:37:17 PM
> >> Subject: Re: ES6 lexical temporal dead zone has landed on central
> >>
> >> On 9/15/14 4:43 PM, Shu-yu Guo wrote:
> >>> If you work with JS that contains `let` bindings, you may start
> >>> encountering
> >>> the following two errors:
> >>>
> >>> 1. TypeError: redeclaration of variable foo
> >>>
> >>> To fix, rename the variable or remove the extra `let` if you are
> >>> assigning to an already-bound variable.
> >>>
> >>> These are static errors. You may pass your JS through the syntax
> >>> checker
> >>> in the SpiderMonkey shell (-c) to detect them.
> >>
> >> Much of the `let` fallout being reported is from variable
> >> redeclarations. For compatibility, perhaps TC39 should reconsider
> >> whether `let` redeclarations are worthy of being static errors.
> >>
> >> JS allows you to redeclare vars. Rust allows you to redeclare variables
> >> with `let` (even changing the type!). SpiderMonkey's non-standard JS1.8
> >> allowed you to redeclare variables with `let` (until Shu made it ES6
> >> compatible). Maybe variable redeclarations are not such a big problem
> >> for JS developers.
> >>
> >> chris
> >>
> >>
> >> _______________________________________________
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >> _______________________________________________
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
>
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
