No more modes?

Mark S. Miller erights at google.com
Mon Oct 18 06:49:42 PDT 2010


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> 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-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> 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/6b5e7a2a/attachment.html>


More information about the es-discuss mailing list