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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
