We are in rapid-release hell/heaven.
This means errata can be issued, and engines can implement the better
resolution for those errata, compared to what the last major-version _de
jure_ spec mandated.
Why not?
/be
Adam Klein wrote:
Note that this behavior in v8/Chrome is only about sloppy mode. In
strict mode, v8 implements the ES6 spec (and we'll likely have support
for lexical declarations in sloppy mode soon).
Though I personally agree that the top-level lexical scoping in ES6
seems unfortunate.
On Mon, Aug 31, 2015 at 9:53 AM, Matthew Robb <matthewwr...@gmail.com
<mailto:matthewwr...@gmail.com>> wrote:
Personally I am a fan of Chrome's CURRENT solution:
```
Uncaught SyntaxError: Block-scoped declarations (let, const,
function, class) not yet supported outside strict mode
```
- Matthew Robb
On Mon, Aug 31, 2015 at 12:08 PM, Jason Orendorff
<jason.orendo...@gmail.com <mailto:jason.orendo...@gmail.com>> wrote:
Hi everyone. Can we talk about the global lexical tier?
This was a mistake, a real blunder. We all should have known
better.
An extensible intermediate scope implies dynamic scoping. The
referent
of an identifier can change only once, but it can change. It's
like an
implicit `with` block around *all code*.
This pattern for declaring variable in multiple scripts won't work
with let/const:
var MyES3Module = MyES3Module || {};
There's no workaround except "keep using var".
It's now possible to get a binding permanently wedged, which
is bad for a REPL:
js> let z = Maht.PI; // oops, typo
ReferenceError: Maht is not defined
js> z
ReferenceError: binding is not initialized: "z"
js> z = 1;
ReferenceError: binding is not initialized: "z"
js> delete z;
false
js> let z = 1;
SyntaxError: redeclaration of variable: "z"
For a single name to have two global bindings, both mutable,
is astonishing.
All of this was unnecessary. What's the benefit to users? We ran
roughshod over existing practice, invariants, and expectations in
order to obtain a kind of self-consistency for `let` that
users don't
expect or even care about.
We should have just made toplevel let/const/class create global
properties, like var. This is how it was proposed originally
and how
Babel implements it today. For SpiderMonkey, switching to the
worse,
less user-friendly way without regressing performance is
time-consuming.
We knew all this. We didn't evaluate it correctly. What we
particularly missed is that we already had modules as the way
forward
to a nice toplevel lexical tier, and weird half measures for
scripts
were pointless.
-j
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
