ES6 opt-in, reloaded

David Herman dherman at mozilla.com
Mon Jan 16 18:12:04 PST 2012


On Jan 16, 2012, at 6:00 PM, Allen Wirfs-Brock wrote:

> On Jan 16, 2012, at 5:49 PM, David Herman wrote:
> 
>> On Jan 16, 2012, at 5:47 PM, Allen Wirfs-Brock wrote:
>> 
>>> One of the thing that an "ES6" (or "extended code" as it is currently known in the ES6 draft) mode  that is distinct from "strict mode" does is allow us do add additional Early Errors that aren't in ES5 for various existing constructs.  It isn't clear that we could continue to have add these errors if we don't have this "mode" distinction as they are generally potentially breaking changes.
>> 
>> The distinction still exists; it's just "code that is syntactically contained within a module."
> 
> Except that it isn't clear to me that such a syntactically scoped mode would be compatible with other goals expressed by others on this thread such as, for example, avoiding refactoring pitfalls.

The only way to avoid refactoring pitfalls entirely is to avoid making any changes in the language altogether. Whether you make changes via a pragma, a MIME type, or a new kind of language construct, you have to deal with refactoring code between the two. Tying it to a syntactic context does mean that the barrier to refactoring is lower, but that's why it's all the more important for us to keep the changes relatively smooth. For example, typeof null is a non-starter in my book.

I believe we should do our best to avoid refactoring pitfalls as much as possible, but I can live with a few (e.g., differing scope rules for block-local functions, arguments aliasing, eval scoping, special cases for destructuring + arguments) in exchange for the drastic improvement to developers' cognitive load, the vastly improved adoption story, and the unity of the spec.

Dave



More information about the es-discuss mailing list