Re: ES6 lexical temporal dead zone has landed on central
I'm with Jeff on this one. I'm very much against special casing add-on code --
which will invariably develop into another compatibility to break when we
finally do decide to break it.
- Original Message -
From: Jeff Walden jwalden+...@mit.edu
To: dev-platform@lists.mozilla.org
Sent: Friday, September 19, 2014 5:51:38 PM
Subject: Re: ES6 lexical temporal dead zone has landed on central
On 09/18/2014 04:18 PM, Kent James wrote:
Substituting var for let does not result in code that behaves identically to
previous code, so I can't see why that would be proposed.
The proposal would be to perform the substitution only for let at body level
of a function. (And for global let -- which requires its own semantic changes,
see bug 589199, that are in progress but not complete yet.) So this:
let s = valid;
{ let s = invalid;}
dump(s);
would be converted to this:
var s = valid;
{ let s = invalid;}
dump(s);
with no semantic change.
This substitution is absolutely not a good idea in the long run. In the short
run, for a release or two...maybe. But that's a vry hesitant maybe. I'm
leery of introducing these deviations into the language, such that people write
code expecting the standard semantics and are surprised to find the code
doesn't work as expected in other contexts. How should addons that inject code
into pages behave, for that code? Is this something that an addon author could
easily predict? I could well imagine it working either way. I'd really rather
not go down this path if we can help it.
Jeff
___
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
Re: ES6 lexical temporal dead zone has landed on central
On 09/18/2014 04:18 PM, Kent James wrote:
Substituting var for let does not result in code that behaves identically to
previous code, so I can't see why that would be proposed.
The proposal would be to perform the substitution only for let at body level
of a function. (And for global let -- which requires its own semantic changes,
see bug 589199, that are in progress but not complete yet.) So this:
let s = valid;
{ let s = invalid;}
dump(s);
would be converted to this:
var s = valid;
{ let s = invalid;}
dump(s);
with no semantic change.
This substitution is absolutely not a good idea in the long run. In the short
run, for a release or two...maybe. But that's a vry hesitant maybe. I'm
leery of introducing these deviations into the language, such that people write
code expecting the standard semantics and are surprised to find the code
doesn't work as expected in other contexts. How should addons that inject code
into pages behave, for that code? Is this something that an addon author could
easily predict? I could well imagine it working either way. I'd really rather
not go down this path if we can help it.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: ES6 lexical temporal dead zone has landed on central
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
Re: ES6 lexical temporal dead zone has landed on central
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
Re: ES6 lexical temporal dead zone has landed on central
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
Re: ES6 lexical temporal dead zone has landed on central
On Thu, Sep 18, 2014 at 1:41 AM, Bobby Holley bobbyhol...@gmail.com wrote: 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. Though I also think that developers will appreciate using real JS. And presumably the current JS semantics were created for good reasons and actually something that authors ultimately prefer. So I don't think we should think of converting to standard semantics here as purely a cost. Ultimately I think we should check with addon authors before making a decision one way or another. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ES6 lexical temporal dead zone has landed on central
On 9/17/2014 7:51 PM, 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
Substituting var for let does not result in code that behaves
identically to previous code, so I can't see why that would be proposed.
These two snippets give different results:
let s = valid;
{ let s = invalid;}
dump(s);
gives a different result than
var s = valid;
{ var s = invalid;}
dump(s);
If you wanted a reasonable compromise, only flagging the duplicated
definition of let in strict mode would be a viable solution.
:rkent
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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
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
Re: ES6 lexical temporal dead zone has landed on central
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
Re: ES6 lexical temporal dead zone has landed on central
On 16/09/2014 07:43, Shu-yu Guo wrote: Hello all, Everything inside mozilla-central needed to make the tree green on TBPL has been fixed. However, this is expected to break addons, comm-central, and possibly B2G code that use `let` (though I was told last time that Gaia does not use `let`). Hello! In future please remember to file appropriate bugs in comm-central *before* landing such tree-wide changes. Your cooperation is appreciated. Yours sincerely, Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ES6 lexical temporal dead zone has landed on central
On 16/09/2014 09:09, Philip Chee wrote: On 16/09/2014 07:43, Shu-yu Guo wrote: Hello all, Everything inside mozilla-central needed to make the tree green on TBPL has been fixed. However, this is expected to break addons, comm-central, and possibly B2G code that use `let` (though I was told last time that Gaia does not use `let`). Hello! In future please remember to file appropriate bugs in comm-central *before* landing such tree-wide changes. Your cooperation is appreciated. Sorry, but I have to correct you. This is NOT a requirement on gecko/Firefox developers. If we can get notification (via cc, this list, other lists or via bugs) of big, potentially-breaking changes, before they land, that is appreciated and is useful to us as it helps save time. However, we recognise this isn't always possible/practical (or remembered). It is the responsibility of comm-central maintainers/developers to ensure any necessary bug filing takes place. This doesn't stop gecko/Firefox developers from filing bugs and helping us out, but it certainly isn't a requirement. Mark. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ES6 lexical temporal dead zone has landed on central
On 9/16/14 11:20 AM, Mark Banner wrote: If we can get notification (via cc, this list, other lists or via bugs) of big, potentially-breaking changes, before they land, that is appreciated and is useful to us as it helps save time. However, we recognise this isn't always possible/practical (or remembered). I agree with Mark here, its nice to get bugs filed but its surely not a requirement. IIRC then this was also announced on the list a while back, so everything that could have been done has been done. Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ES6 lexical temporal dead zone has landed on central
On 9/16/2014 2:39 AM, Philipp Kewisch wrote: On 9/16/14 11:20 AM, Mark Banner wrote: If we can get notification (via cc, this list, other lists or via bugs) of big, potentially-breaking changes, before they land, that is appreciated and is useful to us as it helps save time. However, we recognise this isn't always possible/practical (or remembered). I agree with Mark here, its nice to get bugs filed but its surely not a requirement. IIRC then this was also announced on the list a while back, so everything that could have been done has been done. Philipp See bug 1054357 that I filed for this issue on 2014-08-15 based on the 2014-08-13 m.d.platform post. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ES6 lexical temporal dead zone has landed on central
On 17/09/2014 01:10, Kent James wrote: On 9/16/2014 2:39 AM, Philipp Kewisch wrote: See bug 1054357 that I filed for this issue on 2014-08-15 based on the 2014-08-13 m.d.platform post. Ah, I was on holiday for most of August so I never saw that. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
ES6 lexical temporal dead zone has landed on central
Hello all, Today I landed bug 1001090 (assuming it doesn't bounce), implementing ES6 lexical temporal dead zone for function-level `let` declarations, on mozilla-central. As a refresher on the email I sent on Aug. 13, this is a backwards-incompatible change. Everything inside mozilla-central needed to make the tree green on TBPL has been fixed. However, this is expected to break addons, comm-central, and possibly B2G code that use `let` (though I was told last time that Gaia does not use `let`). 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. 2. ReferenceError: can't access let declaration `foo' before initialization These are hoisted uses and wacky cases like accessing a `let` binding declared in one switch case in a different case. To fix, don't do those things please. These are dynamic errors. You have to execute your JS to detect them. -- shu ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
