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>
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> 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
>> 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
