Kris from the Add-ons Team is already looking into this and will message
developers affected by this issue.
Jorge
On 9/18/14, 1:47 AM, Philipp Kewisch 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
