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
