Opt-in versioning (was: Re: Surprising semantics)

[Brendan Eich]

On Jul 18, 2008, at 6:41 PM, Waldemar Horwat wrote:

> We've been down this road before, and the arguments you present  
> have been hashed out over years.  This approach doesn't work.  Read  
> the archives of the ES4 group.

Specifically, from the March 2008 meeting:

* ES3.1 and ES4 will both allow ‘function’ inside control flow  
statements [directly inside an explicit block, not as the lone  
unbraced consequent statement of an if, while, etc. /be], and it will  
be hoisted to the top of the block and initialized on block entry (to  
be compatible with how functions behave in ES3)

* For ES4, ‘const’ is also scoped to the block, it is not hoisted,  
there is a read barrier, and it’s assign-once

* For ES4, ‘let’ behaves like ‘const’ except that it’s not assign-once

[end edited citation from the minutes. /be]

This was Waldemar's counter-proposal to cut the gordian knot of too  
many declarative forms, some of which allow nonsense or wrongful  
capture. It's good, but it is also not compatible with the current  
browsers' intersection semantics for functions in blocks.

This change requires opt-in versioning, which can be done based on  
page-specified MIME types, following RFC 4329 and HTML 5 and real- 
world browser implementations. Note that script content typing  
depends on in-page type specification -- not on server MIME type to  
suffix mappings.

For overconstrained problems created by different implementations  
operating within the rules of ES3 Chapter 16, there's no credible way  
forward other than opt-in versioning. That's what ES4 proposes. It is  
required for any block-scoped function, and even for const, since you  
can't get const past IE.

When this last came up, the suggestion as I understood it was for IE  
to be handled via scripted user-agent sniffing, presumably  
controlling document.write or DOM creation of script src= loading the  
const-ful or const-less code (or possibly eval, but eval does not  
scale). This is opt-in versioning by another name (the page author  
still has to opt and control script src, if not script type), and  
it's a bad idea to boot. User agent string contents are hard enough  
to parse, and overloaded for too many content-negotiation purposes  
already.

My hope in this follow-up is twofold:

* To highlight the need for opt-in versioning to clean up and evolve  
the language beyond certain points where it otherwise gets stuck.

* To point out that script content type depends on in-page type  
selection mechanism, relieving the worry that was expressed recently  
during an ES3.1 conference call about server file-suffix-to-MIME-type  
mis-configuration.

There are other possible ways to select version, including "use  
version N" pragma-strings. We haven't talked much about these, but  
they can be considered if their effects can be committed before the  
rest of the source following such a pragma is parsed. In light of all  
the possible ways before us, and the precedent in Mozilla for JS  
script types, the conclusion that opt-in versioning is infeasible or  
impractical needs to be demonstrated, not assumed.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080718/9db0de4e/attachment-0002.html