On 16 January 2012 19:35, Brendan Eich <bren...@mozilla.org> wrote: > >> It's also worth noting that backporting > > That is a loaded verb-form ("backporting"). Who says there is a separate > older spec or implementation to which to port? > > Yes, analyzing interactions requires reading the ES5 spec in non-strict mode. > No, the result is not necessarily a port -- it's a patch (if you insist on > hacking metaphors). > >> new ES6 features to classic >> mode, as has been proposed by several people, clearly works against >> (3), > > I object. 3 is misstated to assume "switching" means all-or-nothing. If ES6 > has new features and they are worth using, developers will want to use them > piecewise and conveniently. Assuming they will do so at the price of a > leading "use version 6" or equivalent pragma is debatable. We shouldn't just > assume this conclusion.
OK. But that sounds like a clear departure from the "ES.next/Harmony is based on strict mode" axiom that everybody seemed to have agreed on long ago. Do we have consensus on abandoning that goal? (Thus my description as "backporting".) >> and consequently, also against (5/6). > > This does not follow. Users transitioning to use new features may be helped, > not hindered, by we spec and implementation editors working harder. In > particular allowing, e.g., destructuring in non-strict code may be boon to > developers, whereas requiring them to maintain explicit opt-in pragmas before > doing so simply to convenience spec editors and implementors may be a global > loss. Adding new features to both modes is almost guaranteed to lead to new items to the list of non-strict vs. strict mode differences. That implies new refactoring risks. I don't see a way around that. >> Similarly, opting in at >> smaller scope, as has also been discussed, is a blatant violation of >> (6) and (7), and works against (3), too. > > Let's agree, based on your earlier arguments and also on Dave's point that > lexical scope (free variable error analysis) won't work if opt-in is too > local. OK, I'm really glad. :) >> 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. > > You are arguing based on "simplest" without considering real-world usability. > Too much a-priori system building makes a crashed sky castle, I've seen this > over and over. On the web, a-posteriori wins. > > On the web, people lose version opt-in pragmas and MIME type versions (Larry > Masinter made this point about the latter but it applies to the former). On > the web, we have "use strict"; in the middle of concatenations. We have > Unicode BOMs in the middle. So you are saying that there still will be a refactoring hazard. Agreed, but it is tiny compared to the other proposals. > Meanwhile, JS1 grew via ES1-5 and various implementations (SpiderMonkey and > Rhino) without any such opt-in, *except* for two keywords we couldn't reserve > (and some incompatible change attempts that failed, vs. goal 8 -- one > example: I tried to make == and != strict in JS1.2 to get ES1 to switch, but > that broke the web, wherefore === and !==). Doesn't that kind of make my point? Breaking changes, even small, need opt-in. Strict mode has quite a few of them. Programmers need to be aware of these. I claim that hiding the opt-in locally behind some rather unrelated language feature will not make anybody's life simpler (even if perceived otherwise). > 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. > > Why first if (as Dave's proposal in its minimal form did) a later module > cannot affect earlier non-strict top level semantics? Again there is no > backward compatibility issue. Why, as spec writer or implementor, do you care > whether it's > > <script> > // non-strict top level code > </script> > <script> > module {...} > </script> > > or the concatenation? As an implementer, I don't necessarily. But as a programmer, I want an easy way to tell the meaning of a local piece of code I'm reading. If the place to opt-in is the beginning of the script, that's the only place I have to look. If not, I potentially have to parse all the preceding program text. >> 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). > > Another assumption. There may be more carrots this time, but if the explicit > opt-in requirement is too unusable in practice, then ES6 may bounce, or > simply have slower adoption that we'd like, ceteris paribus (many variables > here, hard to project -- let's avoid arguing based on our favored > speculations). Dave makes this argument, too. I don't know, I may be naive, but I have a very hard time believing that anybody would seriously consider missing out on all the ES6 goodies only because he doesn't like writing one additional, mechanic declaration. I agree, "use version 6;" looks awful. (Mentioning specific versions seems like a suboptimal idea anyway.) Dave suggested "use module;" (albeit with a somewhat different meaning). Why not just "module;"? Then the rule could be even simpler: the first token decides. :) /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss