ES6 doesn't need opt-in

Mark S. Miller erights at google.com
Sun Jan 8 08:28:22 PST 2012


On Sun, Jan 8, 2012 at 8:15 AM, Brendan Eich <brendan at mozilla.com> wrote:

> On Jan 8, 2012, at 8:10 AM, Mark S. Miller wrote:
>
> On Sat, Jan 7, 2012 at 11:05 PM, Brendan Eich <brendan at mozilla.com> wrote:
> [...]
>
>>  so are we really just arguing about names or labels? If so, great --
>> those are important to get right.
>>
> [...]
>
> While I agree it's important to get labels right, if that is indeed the
> only remaining issue here, that's wonderful. I'm mellow about labels others
> find attractive, as long as we agree on observables.
>
> I think there is an observable difference between what I'm advocating and
> what Allen is. Not as sure about your position.
>
>
> I think the only open issue is whether
>
>   "use strict";
>
> opts into completion reform and any other semantic change that does not
> have a syntactic trigger.
>
> 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.

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.


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).


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


More information about the es-discuss mailing list