On 16 January 2012 19:35, Brendan Eich <[email protected]> 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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
