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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
