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
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
