ES6 doesn't need opt-in

Brendan Eich brendan at mozilla.com
Fri Jan 6 11:58:01 PST 2012


On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote:

> AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes?

Counting modes is not productive, is it? All major implementations have extended ES5. It's likely extensions will continue to precede standardization. Do these make ongoing new modes?

Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, Curr&Next, and Curr-Next labels.

/be



> 
> On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 
> On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote:
> 
> > No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode.
> >
> > For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec.
> 
> Implementations that currently support extensions to ES5 (and wish to continue to support them) must classify their extensions into one of the four categories I identified and then process them according to the state machine. Because no currently implementation of function declarations within blocks (that I'm aware of) matches the ES6 lexical scoping semantics, it would expect such function declarations to be classified as ES5~ES6.  Then, according to the state machine, a program like:
> 
> function f(g) {
>   //not the following will produce inconsistent results among common browsers
>   if (!g) {
>      function g() {return 1}
>   }
>  else if (typeof g !== 'function') {
>     function g() {return 2}
>   }
>   return g;
> }
> 
> will be processed using the (implementation extended) ES5 specification and both f and g would presumably be non-strict functions.  If you wanted the above to be processed as ES6 code you would need to add some ES6-only features such as: let ES6; or use some other forced opt-in such as a version in the MIME type.
> 
> The above is exactly analogies to how any "standard" ES5~ES6 features would be treated.
> 
> Allen
> 
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120106/3bb7d206/attachment-0001.html>


More information about the es-discuss mailing list