On 18.10.2010 17:54, Mark S. Miller wrote:
On Mon, Oct 18, 2010 at 6:47 AM, Dmitry A. Soshnikov <dmitry.soshni...@gmail.com <mailto:dmitry.soshni...@gmail.com>> wrote:P.S.[2]: also it seems I missed something, can someone clarify -- are `let` and `const` are removed from Harmony proposals since they shouldn't appear in ES5-strict (in the recommendations for implementations as I see) and since ES6 will be built on ES-strict?No. We recommend that ES5/strict implementations reject 'let' and 'const' for now, so that there's no established divergent semantics by the time we codify their harmony semantics. Once there harmony semantics are adequately settled, proceeding to implement them in ES5/strict would be fine. Likewise with nested named function declarations.
Yep, also thanks, I already got it too (just was confused with a formulation).
Dmitry.
P.S.[3] @MarkMiller: just a small (off-topic) clarification: do new `Object.getPropertyDescriptor` and `Object.getPropertyNames` consider in _addition_ prototype chain or start lookup from the first object in the prototype chain? Because I need to implement JS shim for these two things and seems I understood not correctly e.g. `Object.getPropertyDescriptor` which doesn't consider own properties, but starts its analysis from the first object in the prototype chain. On 18.10.2010 14:17, Dmitry A. Soshnikov wrote:(At last I've read this thread; I'll answer not for this exact letter, but in general). So, there are two backward compats issues: 1. Running an old code (with possible naming conflicts such as `let`, `const`, etc) in a new (ES6) engines; thus, there is no new syntax involved; 2. Running new code in the old engines (the issue with a new syntax). For the first sub-problem a `use harmony;` directive can be enough. This also will work in non-browser host environments (such as CommonJS / Node.js). However, in a view of exactly a pragma directive (i.e. not as a "use strict"; string literal) it will cause the second issue, i.e. a syntax error in all browsers (just right at the first line because they won't be able to parse this pragma). But, being in the "use harmony"; view (as a string literal) also won't solve the issue. Because old browsers even if won't fail on the first line, will do it later when find a new syntax (because the code will be ran anyway). So for exactly old browsers the approach with: <script type="harmony"> </script> seems good (if not the only possible) since this block won't be even parsed/executed. And for server-side JS -- there the approach a little different: the same the new code in old engines won't work -- syntax errors (and seems there are no other obvious ways to prevent it besides checking the MAX_ES_VERSION and require(...) dynamically needed code). But more likely, on the server side it's cheaper and easier to update the engine which support the new syntax (thus, even "use harmony;" isn't needed -- so <script type="harmony"> seems wins -- because the issue mostly touches exactly browser host environments). P.S.: and experiments with <script-if-else> may be leaved for more needed cases. Dmitry. On 15.10.2010 21:30, Brendan Eich wrote:On Oct 14, 2010, at 3:47 PM, Brendan Eich wrote:Seriously, we don't want a version lattice with bad combinatorics. We've been over this in TC39 meetings and there are records on the wiki. The prominent memento is 3(I) at: http://wiki.ecmascript.org/doku.php?id=harmony:harmony#meansPrior to Means 3(I), there is Goal 4 (http://wiki.ecmascript.org/doku.php?id=harmony:harmony#goals): # Keep versioning as simple and linear as possible. We don't have concrete plans for a "use strict" in Harmony to opt into a "stricter than ES5 strict" mode. The "no more modes" plea is good as far as it goes (just not absolute), so I hope we do not add any such Harmony-strict-mode. We're really trying not to make an N-dimensional version/mode/pragma lattice. But, again, ES5 makes incompatible (slight) changes to the de-facto standard JS ("ES3R") language, and ES5 strict is indeed a mode. New syntax is coming, but we will build it on ES5 strict under some kind of opt-in. The minimum opt-in mechanism, we think, is specified by RFC4329: <script type="application/ecmascript;version=6">. This works in IE9, in the sense that the script tag content is not processed (thanks to Jeff Walden for testing). Testing in older and other browsers welcome,with and without the ;version= parameter. Markup-based version selection, to allow inline, out of line (src=) with prefetching, and downrev-browser fallback without "autoconf-style" generation of script elements, seems worth considering.- Will we have to add yet another mode each time we add syntax? After enough iterations this becomes unsustainable.Languages don't grow indefinitely but JS syntax (and semantics) are gappy enough there could be another edition that comes after the first Harmony edition.That was a bit too neutral-sounding. I want to add that my strong desire is to avoid adding syntax after the "Harmony edition" (let's hope it is ES6, but we have been burned picking numbers prematurely in the past, and there's no need yet to pick a number). I'm simply skeptical about our ability to predict the future or enforce a bad prediction. Modules should give everyone writing libraries (least of all TC39) name-conflict-free upgrade paths, along with lexical scope all the way up (no global object). If we ever get to the promised land of macros, we'll need modules (and a lot else; macros are very much a dark horse, or just a gleam in my eye). So modules are important. Proxies too. So are let/const/function-in-block. Some less critical but worthwhile conveniences matter too, enough that they're in the harmony section of the wiki. If you ask me, the list outlined in the last paragraph is enough for "Harmony". I'm not sure we need classes or traits in the language; more work (under way) is needed to find out. My two cents, and as usual I reserve the right to change my mind, or coins. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss_______________________________________________ es-discuss mailing list es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
