ES6 “modes” and user-friendliness

Brendan Eich brendan at mozilla.org
Tue Jan 17 00:27:21 PST 2012


> Axel Rauschmayer <mailto:axel at rauschma.de>
> January 17, 2012 12:06 AM
>
>
> Ah, that makes sense, the thread you mentioned got me confused. Then 
> for language implementors, there are three modes/semantics:
>
> 1. module => ES6 – some changes break with ES5.strict

"some changes break with ES5.strict" is confusing -- do you mean 'let' 
works instead of being a future reserved word, whereas in (3, below) 
'let' is not reserved at all?

> 2. "use strict" => ES5.strict + all ES6 constructs that are 
> backward-compatible
> 3. otherwise => ES3 + all ES6 constructs that are backward-compatible
>
> It’s a tiny bit messy, but I can see that for developers, the illusion 
> of a single ES6 is more or less intact. Seems like the best possible 
> solution.

Agreed.
>
> Given that most people are bound to use modules and given that they 
> are a very convenient “switch”, wouldn’t it be best to introduce as 
> many breaking changes via #1 now (as opposed to later, in ES7 etc.)? 
> Especially removing window from the scope chain.

Dave proposed *not* removing the global object, but keeping the free 
variable error analysis. Most of the win is in the latter, for users. 
Indeed removing the global object is harder for implementors who've 
already sunk the cost, and lots of JS that might want to migrate into 
module {...} to get early typo errors depends on window.foo aliasing var 
foo (object detection at top level).

If you mean other breaking runtime changes, please note that early on a 
bunch of us threw in the towel on typeof null == "null". We're still 
hopeful for completion reform, but Dave's proposal ups the ante: runtime 
semantic shifts are bad for users and implementors, worse than before 
with whole-script opt-in.
>
> Mark’s email [1] seems to suggest just two modes (#1 being a superset 
> of #2 = subsuming it), but using module as a switch, distinguishing #1 
> and #2 might be worth it.
>
> [1] https://mail.mozilla.org/pipermail/es-discuss/2012-January/019195.html

I think counting modes has to count to three, as you enumerated above 
(if I understand your (1) correctly).

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120117/34ca00f4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1222 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120117/34ca00f4/attachment.jpg>


More information about the es-discuss mailing list