ES6 doesn't need opt-in

Brendan Eich brendan at mozilla.com
Sun Jan 8 10:32:34 PST 2012


On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote:

> I'm ok with trying completion reform as an extension to "use strict"; in ES5+ implementations, ASAP -- more than ok, really. It would help prove completion reform is non-breaking.
> 
> That is an example of the kind of issue I am concerned about -- and it is much more than a terminology difference. Any other cleanups we do in ES6 --- that we believe to be practically backward compatible with ES5-strict practice but not with the normative spec nor with test262 --- would fall into the same category as completion reform. So the status of things like we imagine completion reform to be, whether or not completion reform itself is one of those, is something we need to resolve. 

Yes. This is not easy to resolve by a-prior reasoning, though. We might just do nothing incompatible, but we could also probably get away with completion reform and your fixing-override-mistake change. Some experimentation in nightly and even longer-lived/used builds is required.


> The other change I hope fits into the same bucket is <http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake>. Right now, because of pressure from test262, we are in danger of having all browsers conform to this mistake, at which point it may be too late to fix it. Today, the diversity of actual browser behaviors means it is still possible to fix this mistake, much as the diversity of ways ES3 implementations were broken made it possible for ES5 to fix many mistakes.

The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC and (because V8 was drafting off JSC) V8 don't nullify all that history.

On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a real-world case where this matters, even with Object.create. And I see the ocap (not just SES) appeal of the fix.


> And there is one further issue I think is worth clearing up in email here.
> 
> What do we expect to be the normative status of the state machine itself and of the ES5 spec, after ES6 becomes official, for a browser that claims to be standards compliant, including ES6 compliant? AFAICT, no one has commented on this specifically, and we may be reading different assumptions into Allen's proposal.
> 
> What I am assuming Allen's proposal means is that the state machine would also be normative, and therefore those parts of the ES5 spec that are reachable from this state machine would remain normative as well. As I understand ECMA rules, it would be at least unusual for the earlier edition of the spec to remain normative even for systems claiming conformance to the later edition of the "same" spec. (same by spec number, i.e., 262).

I wrote in a previous reply that we aren't preserving ES5 as a spec referenced from ES6. ES6 will be self-contained. So I still don't grok your concern here.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120108/f365e165/attachment.html>


More information about the es-discuss mailing list