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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
