Great summary of the goals, and I agree with the plea for starting with "opting into ES6 through one simple declaration on the top of a program (and nowhere else). Otherwise it's ES5 unchanged."
#6 has other variants as well, such as copy/paste hazards and even subtler concatenation hazards, which are the kinds of issues that will be common for breadth JavaScript developers. Luke -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Andreas Rossberg Sent: Monday, January 16, 2012 8:10 AM To: [email protected] Subject: ES6 opt-in, reloaded Some of the recent discussion regarding ES6 opt-in has been rather... scary. I would like to step back a bit, and try to identify the goals that we actually want to achieve. I think these are: 1. Make ES6 opt-in as convenient as possible. 2. Avoid reliance on external features like script tags or mime types. (Not all JS is on web pages anyway!) 3. Provide as many incentives for switching to ES6 as possible. 4. Minimize necessary changes in programming style. 5. Minimize ES5-ES6 transitioning pitfalls. 6. Avoid maintenance or refactoring pitfalls in ES6 itself. Avoid that ES6 programmers have to think about modes or feature sets at all. (This particularly should apply to non-savvy programmers!) 7. Minimize semantic complications (which tend to harm both implementations and programmers). 8. Obviously, achieve full backwards compatibility. The various proposals in the thread were primarily aimed at (1), but AFAICS all fail on (6), to different extent. (There were mixed results for the other points.) Consequently, programmers would have to be aware which features put them into ES6 (and thus strict mode), and which are only available there, and that local changes could subtly change the meaning of unrelated program parts (due to strict mode), or even the whole program. Moving code could subtly change its internal meaning. It's also worth noting that backporting new ES6 features to classic mode, as has been proposed by several people, clearly works against (3), and consequently, also against (5/6). Similarly, opting in at smaller scope, as has also been discussed, is a blatant violation of (6) and (7), and works against (3), too. So I have plea: let's keep it simple. Start from the simplest of all possible ideas and optimize from there. That is, opting into ES6 through one simple declaration on the top of a program (and nowhere else). Otherwise it's ES5 unchanged. As far as I can see, that clearly wins, or is no worse than other proposals, on anything but (1). Compared to Dave's original proposal, the only scenario on which it loses re (1) is if the program already consists of a module, in which case you'd still have to write the opt-in declaration. One can probably argue whether this is worth adding an extra rule (personally, I don't think so). If so, it would be enough to say that a module declaration as the _first_ statement in the program also opts in _all_ of the program. In either case: 1. You always opt in all of the program consistently. 2. It is obvious from the first line that you do. 3. This truly opts-in the toplevel (for whatever that means in detail). 4. A future ES programmer just needs to know one rule: start your program with _____. (I'm intentionally avoiding bike-shedding a concrete syntax for ____ here.) And before somebody brings it up: I do not fear that this will share the fate of strict mode, because there actually is plenty of incentive for using ES6 (especially, if we do _not_ extend classic mode). /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
