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: Intent to ship: CSS Filters
On Sep 16, 2014, at 9:52 PM, Dirk Schulze dschu...@adobe.com wrote: On Sep 17, 2014, at 2:44 AM, L. David Baron dba...@dbaron.org wrote: On Tuesday 2014-09-16 16:31 -0700, Rik Cabanier wrote: On Tue, Sep 16, 2014 at 2:44 PM, L. David Baron dba...@dbaron.org wrote: On Tuesday 2014-09-16 21:29 +, Max Vujovic wrote: == Interop == Safari, Chrome, and Opera currently ship an interoperable implementation of CSS Filters behind a -webkit prefix. Do they have plans to ship without the prefix? It's not really interoperable if it requires different syntax. Are you suggesting that we should add a '-webkit-filter' property so Firefox is interoperable? No. I'm suggesting that we should try to ensure that Blink and WebKit unprefix sooner rather than later. Shorthand filters are just supported on HTML content in WebKit and Blink. SVG content exclusively works with the unprefixed filter property which currently just supports a reference to SVG filter elements. Once that is fixed, both platforms will support the shorthand functions on unprefixed filter as well. However, it is unlikely that the prefixed property will be removed soon. Shipping CSS filters in Firefox is a strong signal to web developers. The specification is getting finalized and changes to the existing functions must be compatible to the current implementation in WebKit, Blink and Gecko and will not be accepted for level 1 of the spec. Thanks for the info, Dirk. I just asked the question on webkit-dev [1] and blink-dev [2], which might surface other blockers in those projects. At the least, I hope it draws some attention to shipping an unprefixed version. [1]: https://lists.webkit.org/pipermail/webkit-dev/2014-September/026871.html [2]: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/R2gCfHjNgKs - Max Greetings Dirk -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Reminder: Tree Closing Window, Sat Sep 20, 0900-1300 PT
See below for details - to check status, please visit #moc in IRC or https://status.mozilla.org/en-US/calendar/ Main bug for whistlepig: 1065514 Short Summary: Mozilla IT will have a infrastructure maintenance window on Saturday, September 20th, from 0900-1300 PDT. During this window we will be: implementing network improvements, upgrading hg, virtualizing part of the ftp service, and various developer/build resources will be upgraded. Brief network interruptions and reduced network performance in the build environment may be experienced during this window. 1046129: move 63.245.214.0/23 from fw1.scl3 to border[12].scl3 1046136: remove load-balancing from network configurations 1046252: releng/dev-services machines needing reboots during TCW 1057717: fw1.scl3 needs to have security-zone anycast deleted from it 1061879: virtualize upload1.dmz.scl3 1064970: remove ospf passive statement for transit links on border1.pao1 and border1.sjc2 1064974: test convergence time by removing graceful-restart from border1.sjc2 1068520: Mercurial webhead upgrade ___ 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
