No more modes?

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Mon Oct 18 06:51:30 PDT 2010


  Thanks (that means I implemented it wrong before, will fix).

Dmitry.

On 18.10.2010 17:49, Mark S. Miller wrote:
> 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.soshnikov at gmail.com <mailto:dmitry.soshnikov at 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 list
>>>     es-discuss at mozilla.org  <mailto:es-discuss at mozilla.org>
>>>     https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> -- 
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101018/f0acc130/attachment-0001.html>


More information about the es-discuss mailing list