Global lexical tier
SaamBarati1
saambarati1 at gmail.com
Tue Sep 1 03:30:43 UTC 2015
I don't see how strict/sloppy mode effects the behavior of top-level lexical declarations. Does the behavior depend on strict mode?
I agree with Brendan: I vote for changing this if we can.
Saam
> On Aug 31, 2015, at 7:11 PM, Brendan Eich <brendan at mozilla.org> wrote:
>
> 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 <matthewwrobb at gmail.com <mailto:matthewwrobb at 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.orendorff at gmail.com <mailto:jason.orendorff at 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 at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
More information about the es-discuss
mailing list