In addition. The lookups start with the own properties of the objects in question.
On Mon, Oct 18, 2010 at 6:47 AM, Dmitry A. Soshnikov < 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? > > 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#means > > > Prior 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 > listes-disc...@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss > > > > > _______________________________________________ > es-discuss mailing list > 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
