Re: Should const be favored over let?
I've switched to let/const completely. The gain of using const isn't performance (you can statically analyze whether any non-global is potentially assigned to). The gain from const is that it's very very easy for a human to statically analyze. If I see a let binding, I know I need to be a bit more careful with editing that piece of code. I originally thought this'd be a terrible idea, but it's been working great for me. On Thu, Apr 16, 2015 at 10:53 PM, Glen Huang curvedm...@gmail.com wrote: I've completely replaced var with let in my es 2015 code, but I noticed most variables I introduced never change. Should I replace them with const? Will there be any performance gain for most browsers? If so, should such performance gain be considered micro optimization? ___ 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
Re: Final ES6 Draft
The final ES6 ECMAScript 2014 .. aka: *The 2015 ECMAScript Language Specification* Did I say already putting a year in the name was confusing? :P Congratulations Allen and thanks to everyone contributing making this happens. Best Regards P.S. little typo in that page ... This is the final draft of ECME-262 6h Edition ... I believe you meant 6th, not just 6h ;-) On Fri, Apr 17, 2015 at 12:23 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The final ES6 ECMAScript 2014 specification draft has been completed and submitted to the Ecma GA for their consideration and review prior to their June vote to approve it as a standard. The final draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft The only significant technical change in this draft is some tweaks to completion value generation within iteration statements. These tweaks ensure that unroll a loop does not change the resulting completion values. Other changes are minor editorial corrections including a few Ecma styling conformance issues. It will still be possible to make a few very minor editorial corrections before publishings the standard. So please continue to report any bugs or typos you find to bugs.ecmascript.org. ___ 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
Playing with variadric fix point combinators in ES6
I've been playing around with the new syntax for a while, and while searching for a way to get the familiar applicative order Y combinator to handle mutually recursive functions hadn't managed to find a JavaScript example, just Python, Haskell, Scheme, OCaml and of course pure lambda calculus. So I wrote one, though there is really no original work involved except for direct transposition. If anyone wants to program without variables ;) here's a helper for you- http://lpaste.net/130856 or http://www.es6fiddle.com/i8laijui/ -- David liorean Andersson ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Final ES6 Draft
Thanks Allen! Dmitry On Thursday, April 16, 2015, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The final ES6 ECMAScript 2014 specification draft has been completed and submitted to the Ecma GA for their consideration and review prior to their June vote to approve it as a standard. The final draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft The only significant technical change in this draft is some tweaks to completion value generation within iteration statements. These tweaks ensure that unroll a loop does not change the resulting completion values. Other changes are minor editorial corrections including a few Ecma styling conformance issues. It will still be possible to make a few very minor editorial corrections before publishings the standard. So please continue to report any bugs or typos you find to bugs.ecmascript.org. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Should const be favored over let?
There won't be any performance gain. "const" is used to be much slower in v8 actually. But they fixed it as far as I know. I think it's a code style matter. And speaking about that, realistically, most code base will never use "const" widely. Just one reason: 5 characters vs 3 characters to type. So in the name of keeping an amount of different code styles smaller, I'd say stick with "let" (except for obvious constant literals like `const PI = 3.14` on top). Just something to consider. io.js core uses "const" everywhere though. 17.04.2015, 08:53, "Glen Huang" curvedm...@gmail.com:I've completely replaced "var" with "let" in my es 2015 code, but I noticed most variables I introduced never change.Should I replace them with "const"? Will there be any performance gain for most browsers? If so, should such performance gain be considered micro optimization?___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Should const be favored over let?
On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang curvedm...@gmail.com wrote:
I've completely replaced var with let in my es 2015 code, but I noticed
most variables I introduced never change.
Note that `const` has nothing to do with the value of a variable
changing or not. It can still change:
const foo = {};
foo.bar = 42; // does not throw
`const` indicates the *binding* is constant, i.e. there will be no
reassignments etc.
In my post-ES6 code, I use `const` by default, falling back to `let`
if I explicitly need rebinding. `var` is for legacy code.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Should const be favored over let?
@Mathias
Thanks for the clarification. I should use never rebind.
@Alex @Frankie
You guys are right. There won't be any performance gain since it's already
statically analyzable.
FWIW, I opened a feature request on eslint concerning this coding style:
https://github.com/eslint/eslint/issues/2333
https://github.com/eslint/eslint/issues/2333
On Apr 17, 2015, at 8:17 PM, Mathias Bynens mathi...@opera.com wrote:
On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang curvedm...@gmail.com wrote:
I've completely replaced var with let in my es 2015 code, but I noticed
most variables I introduced never change.
Note that `const` has nothing to do with the value of a variable
changing or not. It can still change:
const foo = {};
foo.bar = 42; // does not throw
`const` indicates the *binding* is constant, i.e. there will be no
reassignments etc.
In my post-ES6 code, I use `const` by default, falling back to `let`
if I explicitly need rebinding. `var` is for legacy code.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Please volunteer to maintain the HTML version of the spec
On Thu, Apr 16, 2015 at 3:35 PM, Michael Dyck jmd...@ibiblio.org wrote: I'm interested. OK, thanks. I'll get back to you next week. Unfortunately I'm not around today. Each time a new revision is published, some manual steps are required to map broken links to the right sections in the new document. Do you mean that old 'es6-draft.html' URLs should resolve to the corresponding section in the HTML version of the latest ES7+ draft? (In which case, the latter would need to continue to support (remap) all the old section-ids.) I wonder if people would find that surprising. I hadn't considered it. Given the use cases I know about (mostly es-discuss and in implementations' bug-tracking databases), I think it's better to do it the other way, so that ES6-era links continue to point to an ES6 spec. Starting from scratch will not save a whole lot of work, though. The work required with each revision is mostly figuring out how to redirect section-ids that were newly changed in that revision, not maintaining the old redirects (which is at most some search-and-replace). -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Should const be favored over let?
On 17 April 2015 at 14:17, Mathias Bynens mathi...@opera.com wrote:
On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang curvedm...@gmail.com wrote:
I've completely replaced var with let in my es 2015 code, but I
noticed most variables I introduced never change.
Note that `const` has nothing to do with the value of a variable
changing or not. It can still change:
const foo = {};
foo.bar = 42; // does not throw
`const` indicates the *binding* is constant, i.e. there will be no
reassignments etc.
I have to nitpick on this. In usual nomenclature of programming language
semantics the value in question is the _reference_ to the object (for
types with reference semantics), and that does not change. That the object
itself actually can be mutable is a separate property.
The idea that const somehow applies transitively is a specific idiosyncrasy
of low-level languages like C and friends, that make flattening and copying
of mutable objects an implicit part of their semantics. It is not the norm,
and actually rather contorted semantically.
/Andreas
In my post-ES6 code, I use `const` by default, falling back to `let`
if I explicitly need rebinding. `var` is for legacy code.
___
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
Re: Final ES6 Draft
Congratulations, everyone, on this milestone, and thanks for your work. Looking back all the way to ES5, it's striking just how substantial an improvement ES6 is. It'll ultimately affect almost every line of JS code I write. -j On Thu, Apr 16, 2015 at 6:23 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The final ES6 ECMAScript 2014 specification draft has been completed and submitted to the Ecma GA for their consideration and review prior to their June vote to approve it as a standard. The final draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft The only significant technical change in this draft is some tweaks to completion value generation within iteration statements. These tweaks ensure that unroll a loop does not change the resulting completion values. Other changes are minor editorial corrections including a few Ecma styling conformance issues. It will still be possible to make a few very minor editorial corrections before publishings the standard. So please continue to report any bugs or typos you find to bugs.ecmascript.org. ___ 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
Re: Final ES6 Draft
Allen, this could never have happened without you. Thank you for all the hard work. On Fri, Apr 17, 2015 at 9:32 AM Jason Orendorff jason.orendo...@gmail.com wrote: Congratulations, everyone, on this milestone, and thanks for your work. Looking back all the way to ES5, it's striking just how substantial an improvement ES6 is. It'll ultimately affect almost every line of JS code I write. -j On Thu, Apr 16, 2015 at 6:23 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The final ES6 ECMAScript 2014 specification draft has been completed and submitted to the Ecma GA for their consideration and review prior to their June vote to approve it as a standard. The final draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft The only significant technical change in this draft is some tweaks to completion value generation within iteration statements. These tweaks ensure that unroll a loop does not change the resulting completion values. Other changes are minor editorial corrections including a few Ecma styling conformance issues. It will still be possible to make a few very minor editorial corrections before publishings the standard. So please continue to report any bugs or typos you find to bugs.ecmascript.org. ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are ES6 modules in browsers going to get loaded level-by-level?
Neither node.js/iojs nor nginx. Though nginx supports spdy and there is a http2 module for node but it isn't compatible with express. On Fri, Apr 17, 2015, 2:31 AM medikoo medikoo+mozilla@medikoo.com wrote: Thanks for clarifications, Still after reading your comments I have a feeling that providing ES6 modules to browsers (efficient way) will be much more cumbersome and tricky than it is to provide CJS ones now. This may lead to scenario when most of us (for easy serve of bundle), will prefer to transpile them into something else, but I hope that won't be the case. Another question raises about server support. People are relying on shared (or in cloud) hosting solutions. Do all popular servers (Apache, nginx, or http server in node.js) support HTTP/2 already? Is it easy to configure them to serve es6 modules efficient way? -- View this message in context: http://mozilla.6506.n7.nabble.com/Fwd-Are-ES6-modules-in-browsers-going-to-get-loaded-level-by-level-tp337040p338232.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ 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
Re: Are ES6 modules in browsers going to get loaded level-by-level?
On Thu, Apr 16, 2015 at 11:16 PM, medikoo medikoo+mozilla@medikoo.com wrote: Thanks for clarifications, Still after reading your comments I have a feeling that providing ES6 modules to browsers (efficient way) will be much more cumbersome and tricky than it is to provide CJS ones now. There is no technological reason to have such a feeling. The design of the ES6 module system makes creating bundles much easier and with much less chance of error. All of the imports can be computed from a given root module without relying on the developer build a list or organizing the bundle inputs into folders. This is not true for CJS. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: forward-incompatible Function.prototype.toString requirement
I did some research on this just last year —
http://perfectionkills.com/state-of-function-decompilation-in-javascript/
(and originally back in 2009, when things were much wilder,
http://perfectionkills.com/those-tricky-functions/)
Corresponding tests with notes —
http://kangax.github.io/jstests/function-decompilation/
Just few days ago, I've been also thinking to add tests to ES6 compat table
checking these exact (ES6 introduced) toString representation
requirements from 19.2.3.5.
--
kangax
On Thu, Apr 16, 2015 at 4:33 PM, Mark S. Miller erig...@google.com wrote:
I agree with all this. Let's gather current precedent across JS
implementations of function printings are not and should not be parseable
and see if we can extract a clear spec that is consistent enough with
current reality.
On v8:
Object
function Object() { [native code] }
Object.bind(Object)
function () { [native code] }
On SpiderMonkey:
Object
function Object() {
[native code]
}
Object.bind(Object)
function Object() {
[native code]
}
On JSC:
Object
function Object() {
[native code]
}
Object.bind(Object)
function Object() {
[native code]
}
Looks promising so far! Anyone care to do a more complete investigation
and write up an initial proposal?
On Thu, Apr 16, 2015 at 7:13 AM, Frankie Bagnardi f.bagna...@gmail.com
wrote:
I just meant that it seems confusing that it can both produce a
FunctionExpression
and return a string for which eval will throw a SyntaxError exception.
I didn't mean to highjack this thread; the concern in the original email
is noteworthy. There should be recommended syntaxes which future versions
of the spec agree not to break, including current browser implementations.
This gives any future engines, or modifications to current engines a
clearly defined acceptable way to format these strings.
This also gives libraries which parse functions at runtime (despite how
good of an idea this is) quick bail cases without using eval. Examples of
this are angular and require.js.
On Thu, Apr 16, 2015 at 6:55 AM, Mark S. Miller erig...@google.com
wrote:
On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg rossb...@google.com
wrote:
On 16 April 2015 at 14:34, Frankie Bagnardi f.bagna...@gmail.com
wrote:
The part that sticks out to me is... toString on functions currently
throws a syntax error when eval'd for non-named functions. Tested in
chrome:
var f = function(){ return 1 };eval(f.toString()); // SyntaxError
// becausefunction(){ return 1 }; // SyntaxError
// but, force an expression: eval(( + f.toString() + )) //
essentially clones f
This... is confusing in my opinion.
Yeah, the spec says:
The string representation must have the syntax of a
FunctionDeclaration FunctionExpression, GeneratorDeclaration,
GeneratorExpression, ClassDeclaration, ClassExpression, ArrowFunction,
MethodDefinition, or GeneratorMethod depending upon the actual
characteristics of the object.
which is weird. First, it doesn't really make sense, because whether
something originates from a declaration vs expression isn't a
characteristic of the object. Second, making it return different
syntactic classes in different cases is not particularly useful for your
case.
But then again, using the result of f.toString as input to eval is A
REAL BAD IDEA anyway; toString should only be used for diagnostics, not
programmatically, because that is meaningless in general. So I personally
don't mind the friction.
Disagree. The purpose of this change in toString spec from ES5 is
primarily to support pass-by-copy closed functions. The intent was that it
always work to evaluate them as expressions, i.e., with the surrounding
parens.
http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#there
/Andreas
On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg rossb...@google.com
wrote:
On 16 April 2015 at 11:34, Michael Ficarra
mfica...@shapesecurity.com wrote:
ES2015 section 19.2.3.5 (Function.prototype.toString) places four
restrictions on the output of Function.prototype.toString, one of which
is
If the implementation cannot produce a source code string that meets
these criteria then it must return a string for which *eval* will
throw a *SyntaxError* exception.
What is a SyntaxError today may not be a SyntaxError tomorrow. How
can an implementation return a string that will satisfy this
requirement in
the future when the language has added new syntax? Does the committee
have
a SyntaxError recommendation that can be added as a non-normative note
to
that section?
In the (probably unlikely) case that the language changed that way,
and an affected implementation adopted that change, then it would simply
have to change its toString implementation accordingly at that point. I
don't see a problem there.
/Andreas
Re: Final ES6 Draft (Jason Orendorff)
Awesome work! Truly an exciting milestone. A lot of really nice stuff is in, and the future with ES7 looks bright. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Putting `global` reference in specs
We have `window` in DOM land, `self` in Workers, and `global` in most common server side JS engines ... plus we have this in ES6 specification: In addition to the properties defined in this specification the *global* object may have additional host defined properties. This may include a property whose value is the *global* object itself; for example, in the HTML document object model the window property of the *global* object is the *global* object itself. Now, accordingly with this madness: 8.5 millions checks for `typeof global` https://github.com/search?q=%27typeof+global%27type=Coderef=searchresultsutf8= 14.1 millions checks for `typeof window` https://github.com/search?q=%27typeof+window%27type=Coderef=searchresultsutf8= Does anyone have a concrete reason for NOT specifying **global** as reference to whatever `window` or `self` reference already? I've suggested to stick this on top of every wen page: ```html scriptvar global=global||this;/script ``` and this on top of every Worker ```js var global=global||this; ``` But I'm pretty sure if ECMAScript would have that in specs we might see the end of the debate and the infamouse `typeof window` or `typeof global` check. Thanks in advance for thoughts ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
do while scope
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
On 4/17/15 10:55 AM, Andrea Giammarchi wrote: We have `window` in DOM land, `self` in Workers We have `self` in DOM land too, so you can consistently use `self` across Window and Workers. and `global` in most common server side JS engines Sounds like they should add `self`. ;) -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
We have `self` in DOM land too, so you can consistently use `self` across Window and Workers. Why didn't I know this!? Cool : ) and `global` in most common server side JS engines Sounds like they should add `self`. ;) That would make sense. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: forward-incompatible Function.prototype.toString requirement
On Fri, Apr 17, 2015 at 7:10 AM, Juriy Zaytsev kan...@gmail.com wrote:
I did some research on this just last year —
http://perfectionkills.com/state-of-function-decompilation-in-javascript/
(and originally back in 2009, when things were much wilder,
http://perfectionkills.com/those-tricky-functions/)
Corresponding tests with notes —
http://kangax.github.io/jstests/function-decompilation/
Cool, thanks. Lots of ancient history there. Of recent versions of
browsers / engines, what problems do you see in arriving at ES6 conformance?
Btw, I was amused to see the old Caja es5-to-es3 transpiler case in there:
function f(){}; // function f() { [cajoled code] }
var f = function(){}; // function f$_var() { [cajoled code] }
which does raise the issue of how transpilers should cope with these
requirements. If the source string produced does parse, what language layer
should it be expressed in?
(Note: Modern Caja uses SES, which usually does not transpile)
Just few days ago, I've been also thinking to add tests to ES6 compat
table checking these exact (ES6 introduced) toString representation
requirements from 19.2.3.5.
Please do! Beyond ES6 conformance, it looks like we could plausibly stdize
something like the following for the must not parse case:
The function head should parse as some kind of function head.
The function body must match /^\s*{\s*\[[^{}\[\]]*\]\s*}\s*$/
i.e.,
{ [ non-{}[]-text ] }
The proposal would effectively commit us to never introducing a future
syntax where this parses as a function body, addressing the issue Michael
raises at the beginning of this thread. It would also allow reliable
recognition of those cases intended not to parse for this reason, including
present code recognizing future code (modulo recognizing future function
heads :( ). Does this seem plausible?
Anyone care to write an initial concrete proposal?
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: do while scope
Is there a language where lexically scoped variables declared in a block are
accessible outside of that block? Java, C, C#, rust, Python, etc, will not let
you do this. I’m not sure this is a gotcha for most software developers
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com wrote:
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
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
Re: Putting `global` reference in specs
I know that, reason JSLint complains when used internally instead of `that`, but `self` is the most misleading name ever for whoever comes from Python and PHP or mostly any other language + self is **nowehere** in ECMAScript specifications. So I'd say we should not have `self` (if stays on global and Worker I don't actually care) and add a `global` that nobody needs explanation to understand what it is in JavaScript On Fri, Apr 17, 2015 at 4:02 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/15 10:55 AM, Andrea Giammarchi wrote: We have `window` in DOM land, `self` in Workers We have `self` in DOM land too, so you can consistently use `self` across Window and Workers. and `global` in most common server side JS engines Sounds like they should add `self`. ;) -Boris ___ 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
Re: do while scope
er, to add to that, “a” shouldn’t be undefined during the while condition, this
should throw — it’s a reference error
On Apr 17, 2015, at 11:10 AM, Caitlin Potter caitpotte...@gmail.com wrote:
Is there a language where lexically scoped variables declared in a block are
accessible outside of that block? Java, C, C#, rust, Python, etc, will not
let you do this. I’m not sure this is a gotcha for most software developers
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com wrote:
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
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
Re: Putting `global` reference in specs
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: So I'd say we should not have `self` (if stays on global and Worker I don't actually care) and add a `global` that nobody needs explanation to understand what it is in JavaScript Indeed, three ways to reference the global object is not nearly enough. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: do while scope
Not sure about others, but i assume the condition part and statement part in a
control construct live in the same scope.
That's why you can do `for (let a = 1; a 2; a++) a;`. And `if (let a = 1) a;`
maybe in es7?
Why that's not the case for do while? Is my mental model wrong?
On Apr 17, 2015, at 11:10 PM, Caitlin Potter caitpotte...@gmail.com wrote:
Is there a language where lexically scoped variables declared in a block are
accessible outside of that block? Java, C, C#, rust, Python, etc, will not
let you do this. I’m not sure this is a gotcha for most software developers
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com wrote:
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
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
Re: Template strings flags
Alternative: an operator for function composition. ```js let text = `…` @@ t; ``` On 17 Apr 2015, at 19:13, monolithed monolit...@gmail.com wrote: Why not provide special formatting flags for `Template strings`? ```js let text = `text text text text text text text text text text text text`t; ``` `t` - trim whitespaces Expected result: ```js let text = `text text text text text text text text text text text text`t; ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
As such I think our best bet is for server-side JS runtimes to use `self` or `window`. I personally hope that would never happen, and you managed to over-engineer the simplest alignment requirement I could possibly think of ... indeed ... We might as well move it into the set of terms like realm or vat or environment that are more abstract than real. a new term like realm will just create more fragmentation = https://xkcd.com/927/ + there's no such thing on server side, at least not the same there is on front end vat is at least semantic in this case since it means Value-Added Tax ... but I am back to previous point environment is confusing with `process.env` Let's avoid the introduction of more problems please ... I rather leave things as it is since we are unable to be pragmatic, no matter how straight forward is the solution. On Fri, Apr 17, 2015 at 6:11 PM, Domenic Denicola d...@domenic.me wrote: One thing I'm surprised nobody has brought up yet is that global would be an incorrect name in the case of browsers. The actual global object is not (and must never be) directly accessible. Instead you get a window proxy when you use `window`, `self`, `this`, etc. As such I think our best bet is for server-side JS runtimes to use `self` or `window`. The latter isn't as crazy as it sounds: just start adding phrases to the ES spec like all JavaScript code runs within a certain context, called a _window_, which has a corresponding _window object_. In some runtimes the window object will be equivalent to the global object, but not always. Scripts run within _window scope_, whereas modules run in their own lexical context. The value of **this** in window scope is the window object. It's not as if `window` actually means window anymore, given tabs and iframes and frames. We might as well move it into the set of terms like realm or vat or environment that are more abstract than real. -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Anne van Kesteren Sent: Friday, April 17, 2015 11:19 To: Andrea Giammarchi Cc: es-discuss@mozilla.org Subject: Re: Putting `global` reference in specs On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: So I'd say we should not have `self` (if stays on global and Worker I don't actually care) and add a `global` that nobody needs explanation to understand what it is in JavaScript Indeed, three ways to reference the global object is not nearly enough. -- https://annevankesteren.nl/ ___ 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
Re: Nailing object property order
fwiw, tests for enumeration order now in compat table — https://github.com/kangax/compat-table/commit/a267f2233ce3b25dfbee876f4a4786ad85b31049 Results — https://kangax.github.io/compat-table/es6/#own_property_order -- kangax On Thu, Apr 16, 2015 at 8:37 PM, Brendan Eich bren...@mozilla.org wrote: Also, it's too late. Engines are converging, inter-operation pressure points in one direction only: greater convergence and standardization. It's true engines are not converging on the ancient insertion order, and that caused some interop stress, but we are over that hump now. See https://code.google.com/p/v8/issues/detail?id=164can=1q=enumerationcolspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Area%20Stars (a long, and long-resolved, V8 issue). Bergi's frustration is understandable. Leaving things unspecified for too long was a failure on our part in tending the spec, or a trade-off (we had other things to do ;-). All water under the bridge, but we're not stepping back to unspecified behavior. Because engines aren't, because developers do not want. And agree with Mark: POITROAE. /be Mark S. Miller wrote: Developer productivity hypothetical minor performance gains. +1 to all steps to make the specified behavior more deterministic, including this one. On Thu, Apr 16, 2015 at 10:07 AM, liorean lior...@gmail.com mailto: lior...@gmail.com wrote: I'm very much opposed to locking this down for general objects because it locks the implementation choices for generic objects down. What if the engine backing implementation was, say, some variation of a trie for instance? It cannot really be done today without adding extraneous data into the structure, because lookup in that case happens on a character by character basis, not on a whole string basis, so properties that use common prefixes would always end up adjacent and even if the keys weren't inserted in order by bit patterns into the trie as most implementations do, they would still be grouped by common prefix. -- David liorean Andersson ___ 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 ___ 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
Re: Putting `global` reference in specs
This came up in iojs, did not go over well. https://github.com/iojs/io.js/issues/1043 On Fri, Apr 17, 2015 at 1:11 PM Domenic Denicola d...@domenic.me wrote: One thing I'm surprised nobody has brought up yet is that global would be an incorrect name in the case of browsers. The actual global object is not (and must never be) directly accessible. Instead you get a window proxy when you use `window`, `self`, `this`, etc. As such I think our best bet is for server-side JS runtimes to use `self` or `window`. The latter isn't as crazy as it sounds: just start adding phrases to the ES spec like all JavaScript code runs within a certain context, called a _window_, which has a corresponding _window object_. In some runtimes the window object will be equivalent to the global object, but not always. Scripts run within _window scope_, whereas modules run in their own lexical context. The value of **this** in window scope is the window object. It's not as if `window` actually means window anymore, given tabs and iframes and frames. We might as well move it into the set of terms like realm or vat or environment that are more abstract than real. -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Anne van Kesteren Sent: Friday, April 17, 2015 11:19 To: Andrea Giammarchi Cc: es-discuss@mozilla.org Subject: Re: Putting `global` reference in specs On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: So I'd say we should not have `self` (if stays on global and Worker I don't actually care) and add a `global` that nobody needs explanation to understand what it is in JavaScript Indeed, three ways to reference the global object is not nearly enough. -- https://annevankesteren.nl/ ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Template strings flags
Why not provide special formatting flags for `Template strings`? ```js let text = `text text text text text text text text text text text text`t; ``` `t` - trim whitespaces Expected result: ```js let text = `text text text text text text text text text text text text`t; ``` - Alexander ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Please volunteer to maintain the HTML version of the spec
I could probably come up with a way to include permanent ids in section headings as Word invisible fields. It would be a little more work for spec. editors (and somewhat bug prone: forgetting to include one, forgetting to change the id when copying a heading, etc) but would eliminate the need to maintain an external map. That is a great idea! It may make sense to make each top-level section a separate namespace then it’s easier to keep IDs unique and there is graceful degradation. One way of achieving that is by breaking up the HTML spec into one page per top-level section, but that has disadvantages, too. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Template strings flags
Why not provide special formatting flags for `Template strings`? Tagged template strings are your friend. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: do while scope
Ah, yes, I meant reference error.
I just realized maybe my mental model is wrong:
Is it correct that this is the scope chain for a for loop?
top scope
for condition scope
for statement scope
Statement can reference variables defined in condition, but not the other way
around?
On Apr 17, 2015, at 11:15 PM, Caitlin Potter caitpotte...@gmail.com wrote:
er, to add to that, “a” shouldn’t be undefined during the while condition,
this should throw — it’s a reference error
On Apr 17, 2015, at 11:10 AM, Caitlin Potter caitpotte...@gmail.com wrote:
Is there a language where lexically scoped variables declared in a block are
accessible outside of that block? Java, C, C#, rust, Python, etc, will not
let you do this. I’m not sure this is a gotcha for most software developers
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com wrote:
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
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
Re: Putting `global` reference in specs
On Fri, Apr 17, 2015 at 8:33 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
it's a no-go under CSP so it's as bad as `Function('return this')()`
Precisely. Which raises an interesting point. Does anyone know of a
*precise* statement of the actual threat model that CSP's no eval is
suppose to protect against?
The reason I ask is that I suspect that there's no valid reason for SES's
eval, confine, and Function to be disabled by CSP's no-eval mode.
Indeed, SES-with-eval is much safer for most purposes than JS-without-eval.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Should const be favored over let?
I too have found that most of my variables are defined with const, as they never change. Let var die is a catchy saying, but I believe it should be let var die, use const. On Fri, Apr 17, 2015 at 6:16 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I agree, 'let' is likely to win because of it's length. I find that I fall into using it solely or that reason. I think it also wins on readability. If we had a do-over. I'd make `let` means what `const` now means and have something different for defining mutable lexical bindings. Maybe `let var foo=...;`. let and mut? Oh well, too late for that now. Marius Gundersen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Please volunteer to maintain the HTML version of the spec
On 4/17/15 1:16 PM, Axel Rauschmayer wrote: One way of achieving that is by breaking up the HTML spec into one page per top-level section, but that has disadvantages, too. Indeed. Like the ability to search in it. As a spec consumer, having specs broken up like this makes them much harder to work with. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: do while scope
On 17 April 2015 at 17:18, Glen Huang curvedm...@gmail.com wrote:
Not sure about others, but i assume the condition part and statement part
in a control construct live in the same scope.
That's why you can do `for (let a = 1; a 2; a++) a;`. And `if (let a =
1) a;` maybe in es7?
Why that's not the case for do while? Is my mental model wrong?
Yes. :)
for (let x ...) scopes over the body naturally. In your example, you expect
to scope an inner declaration (one even inside a block) to scope to the
outside. That is something else entirely, and makes no sense to me.
/Andreas
On Apr 17, 2015, at 11:10 PM, Caitlin Potter caitpotte...@gmail.com
wrote:
Is there a language where lexically scoped variables declared in a block
are accessible outside of that block? Java, C, C#, rust, Python, etc, will
not let you do this. I’m not sure this is a gotcha for most software
developers
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com wrote:
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
On 4/17/15 11:27 AM, Mark S. Miller wrote:
(1,eval)('use strict; this')
This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike window, self, or global) ;)
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
oh ... that one, it was for Boris who wrote:
This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike window, self, or global) ;)
I meant that your `eval` wasn't more reliable than window, self, or global,
because ot could have been redefined as well ... but this is not about
shadowability, it's about having one name that fits in every JS situation:
server, worker, document
`global` instead of `window` and/or `self` is a clear win for everyone,
being curse forever to check it `typeof window` or `typeof global` is not
undefined is ... well, the most basic and striking fragmentation case we
have at the root of the language ^_^
On Fri, Apr 17, 2015 at 5:13 PM, Mark S. Miller erig...@google.com wrote:
On Fri, Apr 17, 2015 at 9:05 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I've never said unshadowable ...
You did:
On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
also `eval` can be in-scope redefined as much as global, window, or self,
so no, that's actually not a solution.
I am saying that `global` should be a global reference to the global
object which is mentioned in ES6/2015 but it's not specified how it should
be referenced. `window` is not welcome even in DOM tools like browserify,
`global` is ubiquitous in its meaning, it does not confuse anyone like a
`self` in node.js or others would do, and it will solve forever the hassle
of referencing *by deafault* a global object without needing to eval,
Function('return this'), [].sort(), or whatever wizardy you coudl came up
to retrieve and/or reference the global object.
It's deadly simple: whatever freedom implementors have to put window
and/or self in, they MUST put a `global` reference too ... that will make
everything else redundant, in the long term, and not vice-versa
Is this really that complicated to ship?
On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller erig...@google.com
wrote:
On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
also `eval` can be in-scope redefined as much as global, window, or
self, so no, that's actually not a solution.
Btw, I wasn't asking for a workaround, I was proposing to officially
bring ES 2015 `global` object as language reference in ES7/201X
In an unshadowable manner? Never gonna happen. Everything that provides
authority must be virtualizable.
It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
millions of results in Github for `typeof global` apparently got unnoticed
)
On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
it's a no-go under CSP so it's as bad as `Function('return this')()`
On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu
wrote:
On 4/17/15 11:27 AM, Mark S. Miller wrote:
(1,eval)('use strict; this')
This has the drawback of making eyes bleed, but the benefit of
working reliably (unlike window, self, or global) ;)
-Boris
___
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
--
Cheers,
--MarkM
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Should const be favored over let?
On Apr 17, 2015, at 5:09 AM, Alex Kocharin wrote: There won't be any performance gain. const is used to be much slower in v8 actually. But they fixed it as far as I know. I think it's a code style matter. And speaking about that, realistically, most code base will never use const widely. Just one reason: 5 characters vs 3 characters to type. So in the name of keeping an amount of different code styles smaller, I'd say stick with let (except for obvious constant literals like `const PI = 3.14` on top). Just something to consider. I agree, 'let' is likely to win because of it's length. I find that I fall into using it solely or that reason. I think it also wins on readability. If we had a do-over. I'd make `let` means what `const` now means and have something different for defining mutable lexical bindings. Maybe `let var foo=...;`. But the let/const pairing was a firmly established direction long before work on ES6 even started. There was so much other stuff to work on and so much inertia behind let/const that nobody ever seriously challenged that direction. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: do while scope
Thank you.
I just post my new understanding a few seconds earlier. Hope that's right. :)
On Apr 17, 2015, at 11:28 PM, Andreas Rossberg rossb...@google.com wrote:
On 17 April 2015 at 17:18, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Not sure about others, but i assume the condition part and statement part in
a control construct live in the same scope.
That's why you can do `for (let a = 1; a 2; a++) a;`. And `if (let a = 1)
a;` maybe in es7?
Why that's not the case for do while? Is my mental model wrong?
Yes. :)
for (let x ...) scopes over the body naturally. In your example, you expect
to scope an inner declaration (one even inside a block) to scope to the
outside. That is something else entirely, and makes no sense to me.
/Andreas
On Apr 17, 2015, at 11:10 PM, Caitlin Potter caitpotte...@gmail.com
mailto:caitpotte...@gmail.com wrote:
Is there a language where lexically scoped variables declared in a block
are accessible outside of that block? Java, C, C#, rust, Python, etc, will
not let you do this. I’m not sure this is a gotcha for most software
developers
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
Which would have made virtualization without translation impossible. Glad
we dodged that bullet ;).
On Fri, Apr 17, 2015 at 9:00 AM, Mameri, Fred (HBO) fred.mam...@hbo.com
wrote:
At some point in the past, I proposed that we introduce syntax for that.
In my proposal, prefixing an identifier with a . would create an
unambiguous reference to the global version of that variable.
For example:
```js
var x;
function f(x) {
x; // local
.x; // global
}
```
This is an idea I borrowed from C++’s :: operator.
From: Mark Miller erig...@gmail.com
Date: Friday, April 17, 2015 at 8:53 AM
To: Glen Huang curvedm...@gmail.com
Cc: Mark S. Miller erig...@google.com, es-discuss@mozilla.org
es-discuss@mozilla.org
Subject: Re: Putting `global` reference in specs
This is one of several cases where, post ES6, we can provide a std
module import that provides a built-in that carries authority. Another
example is the constructor for making weak references, which necessarily
provide the ability to read a covert channel. As with shadowable globals,
this module import must be easy to virtualize. We purposely postponed this
along with the Loader and Realm API as it is security sensitive and we
don't yet have enough usage experience with modules to know how to design
this separation well.
In particular, we rejected the obvious Reflect.global as it bundles the
global together with authority-free safe things, which makes virtualization
of the global alone needlessly unpleasant.
On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang curvedm...@gmail.com wrote:
You guys are talking about referencing the global object in modules
right? Since in scripts you can reliably get hold of the global object by
using this in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope
of a module, I guess that means module code really isn't supposed to get
hold of the global object?
On Apr 17, 2015, at 11:34 PM, Mark S. Miller erig...@google.com wrote:
I almost omitted it, but one should never need to encounter or think
about sloppy code unless absolutely necessary. For my brain, adding the
use strict; makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg rossb...@google.com
wrote:
On 17 April 2015 at 17:27, Mark S. Miller erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call
*the global object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker
I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly
enough.
--
https://annevankesteren.nl/
___
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
--
Cheers,
--MarkM
___
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
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
-
This e-mail is intended only for the use of the addressees. Any copying,
forwarding, printing or other use of this e-mail by persons other than the
addressees is not authorized. This e-mail may contain information that is
privileged, confidential and exempt from disclosure. If you are not the
intended recipient, please notify us immediately by return e-mail
(including the original message in your reply) and then delete and discard
all copies of the e-mail.
Thank you.
-
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
(1,eval)('use strict; this')
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the
global object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I
don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
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
Re: Putting `global` reference in specs
Yes, something like that is quite plausible. Note though the difference.
Promise is an authority-free safe thing stdized as a global primordial by
the ES spec, with a behavior spec'ed by the ES spec. Although one might
still wish to virtualize it, the reasons are very different.
On Fri, Apr 17, 2015 at 9:06 AM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
Not so pretty but:
import * as global from “@global”;
Or some bindings:
import {Promise} from “@global”;
*From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Mark
Miller
*Sent:* April 17, 2015 11:53 AM
*To:* Glen Huang
*Cc:* Mark S. Miller; es-discuss@mozilla.org
*Subject:* Re: Putting `global` reference in specs
This is one of several cases where, post ES6, we can provide a std module
import that provides a built-in that carries authority. Another example is
the constructor for making weak references, which necessarily provide the
ability to read a covert channel. As with shadowable globals, this module
import must be easy to virtualize. We purposely postponed this along with
the Loader and Realm API as it is security sensitive and we don't yet have
enough usage experience with modules to know how to design this separation
well.
In particular, we rejected the obvious Reflect.global as it bundles the
global together with authority-free safe things, which makes virtualization
of the global alone needlessly unpleasant.
On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang curvedm...@gmail.com wrote:
You guys are talking about referencing the global object in modules
right? Since in scripts you can reliably get hold of the global object by
using this in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope of
a module, I guess that means module code really isn't supposed to get hold
of the global object?
On Apr 17, 2015, at 11:34 PM, Mark S. Miller erig...@google.com wrote:
I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the use
strict; makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg rossb...@google.com
wrote:
On 17 April 2015 at 17:27, Mark S. Miller erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the
global object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I
don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
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
--
Cheers,
--MarkM
___
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
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
On Fri, Apr 17, 2015 at 9:05 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I've never said unshadowable ...
You did:
On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
also `eval` can be in-scope redefined as much as global, window, or self,
so no, that's actually not a solution.
I am saying that `global` should be a global reference to the global
object which is mentioned in ES6/2015 but it's not specified how it should
be referenced. `window` is not welcome even in DOM tools like browserify,
`global` is ubiquitous in its meaning, it does not confuse anyone like a
`self` in node.js or others would do, and it will solve forever the hassle
of referencing *by deafault* a global object without needing to eval,
Function('return this'), [].sort(), or whatever wizardy you coudl came up
to retrieve and/or reference the global object.
It's deadly simple: whatever freedom implementors have to put window
and/or self in, they MUST put a `global` reference too ... that will make
everything else redundant, in the long term, and not vice-versa
Is this really that complicated to ship?
On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller erig...@google.com
wrote:
On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
also `eval` can be in-scope redefined as much as global, window, or
self, so no, that's actually not a solution.
Btw, I wasn't asking for a workaround, I was proposing to officially
bring ES 2015 `global` object as language reference in ES7/201X
In an unshadowable manner? Never gonna happen. Everything that provides
authority must be virtualizable.
It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
millions of results in Github for `typeof global` apparently got unnoticed )
On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
it's a no-go under CSP so it's as bad as `Function('return this')()`
On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu
wrote:
On 4/17/15 11:27 AM, Mark S. Miller wrote:
(1,eval)('use strict; this')
This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike window, self, or global) ;)
-Boris
___
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
--
Cheers,
--MarkM
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the use
strict; makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg rossb...@google.com
wrote:
On 17 April 2015 at 17:27, Mark S. Miller erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the
global object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I
don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
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
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
also `eval` can be in-scope redefined as much as global, window, or self,
so no, that's actually not a solution.
Btw, I wasn't asking for a workaround, I was proposing to officially bring
ES 2015 `global` object as language reference in ES7/201X
In an unshadowable manner? Never gonna happen. Everything that provides
authority must be virtualizable.
It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
millions of results in Github for `typeof global` apparently got unnoticed )
On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
it's a no-go under CSP so it's as bad as `Function('return this')()`
On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/17/15 11:27 AM, Mark S. Miller wrote:
(1,eval)('use strict; this')
This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike window, self, or global) ;)
-Boris
___
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
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
At some point in the past, I proposed that we introduce syntax for that. In my
proposal, prefixing an identifier with a . would create an unambiguous
reference to the global version of that variable.
For example:
```js
var x;
function f(x) {
x; // local
.x; // global
}
```
This is an idea I borrowed from C++'s :: operator.
From: Mark Miller erig...@gmail.commailto:erig...@gmail.com
Date: Friday, April 17, 2015 at 8:53 AM
To: Glen Huang curvedm...@gmail.commailto:curvedm...@gmail.com
Cc: Mark S. Miller erig...@google.commailto:erig...@google.com,
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: Putting `global` reference in specs
This is one of several cases where, post ES6, we can provide a std module
import that provides a built-in that carries authority. Another example is the
constructor for making weak references, which necessarily provide the ability
to read a covert channel. As with shadowable globals, this module import must
be easy to virtualize. We purposely postponed this along with the Loader and
Realm API as it is security sensitive and we don't yet have enough usage
experience with modules to know how to design this separation well.
In particular, we rejected the obvious Reflect.global as it bundles the global
together with authority-free safe things, which makes virtualization of the
global alone needlessly unpleasant.
On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang
curvedm...@gmail.commailto:curvedm...@gmail.com wrote:
You guys are talking about referencing the global object in modules right?
Since in scripts you can reliably get hold of the global object by using this
in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope of a
module, I guess that means module code really isn't supposed to get hold of the
global object?
On Apr 17, 2015, at 11:34 PM, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the use strict;
makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg
rossb...@google.commailto:rossb...@google.com wrote:
On 17 April 2015 at 17:27, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the global
object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren
ann...@annevk.nlmailto:ann...@annevk.nl wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
-
This e-mail is intended only for the use of the addressees. Any copying,
forwarding, printing or other use of this e-mail by persons other than the
addressees is not authorized. This e-mail may contain information that is
privileged, confidential and exempt from disclosure. If you are not the
intended recipient, please notify us immediately by return e-mail (including
the original message in your reply) and then delete and discard all copies of
the e-mail.
Thank you.
-
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
I've never said unshadowable ... I am saying that `global` should be a
global reference to the global object which is mentioned in ES6/2015 but
it's not specified how it should be referenced. `window` is not welcome
even in DOM tools like browserify, `global` is ubiquitous in its meaning,
it does not confuse anyone like a `self` in node.js or others would do, and
it will solve forever the hassle of referencing *by deafault* a global
object without needing to eval, Function('return this'), [].sort(), or
whatever wizardy you coudl came up to retrieve and/or reference the global
object.
It's deadly simple: whatever freedom implementors have to put window and/or
self in, they MUST put a `global` reference too ... that will make
everything else redundant, in the long term, and not vice-versa
Is this really that complicated to ship?
On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller erig...@google.com wrote:
On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
also `eval` can be in-scope redefined as much as global, window, or self,
so no, that's actually not a solution.
Btw, I wasn't asking for a workaround, I was proposing to officially
bring ES 2015 `global` object as language reference in ES7/201X
In an unshadowable manner? Never gonna happen. Everything that provides
authority must be virtualizable.
It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
millions of results in Github for `typeof global` apparently got unnoticed )
On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
it's a no-go under CSP so it's as bad as `Function('return this')()`
On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/17/15 11:27 AM, Mark S. Miller wrote:
(1,eval)('use strict; this')
This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike window, self, or global) ;)
-Boris
___
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
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
it's a no-go under CSP so it's as bad as `Function('return this')()`
On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/17/15 11:27 AM, Mark S. Miller wrote:
(1,eval)('use strict; this')
This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike window, self, or global) ;)
-Boris
___
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
Re: Putting `global` reference in specs
You guys are talking about referencing the global object in modules right?
Since in scripts you can reliably get hold of the global object by using this
in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope of a
module, I guess that means module code really isn't supposed to get hold of the
global object?
On Apr 17, 2015, at 11:34 PM, Mark S. Miller erig...@google.com wrote:
I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the use
strict; makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg rossb...@google.com
mailto:rossb...@google.com wrote:
On 17 April 2015 at 17:27, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the
global object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/ https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
This is one of several cases where, post ES6, we can provide a std module
import that provides a built-in that carries authority. Another example is
the constructor for making weak references, which necessarily provide the
ability to read a covert channel. As with shadowable globals, this module
import must be easy to virtualize. We purposely postponed this along with
the Loader and Realm API as it is security sensitive and we don't yet have
enough usage experience with modules to know how to design this separation
well.
In particular, we rejected the obvious Reflect.global as it bundles the
global together with authority-free safe things, which makes virtualization
of the global alone needlessly unpleasant.
On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang curvedm...@gmail.com wrote:
You guys are talking about referencing the global object in modules right?
Since in scripts you can reliably get hold of the global object by using
this in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope of
a module, I guess that means module code really isn't supposed to get hold
of the global object?
On Apr 17, 2015, at 11:34 PM, Mark S. Miller erig...@google.com wrote:
I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the use
strict; makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg rossb...@google.com
wrote:
On 17 April 2015 at 17:27, Mark S. Miller erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the
global object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker
I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
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
--
Cheers,
--MarkM
___
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
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Please volunteer to maintain the HTML version of the spec
On Apr 17, 2015, at 6:20 AM, Jason Orendorff wrote: On Thu, Apr 16, 2015 at 3:35 PM, Michael Dyck jmd...@ibiblio.org wrote: I'm interested. OK, thanks. I'll get back to you next week. Unfortunately I'm not around today. We should probably start by forking your repository and hosting it on https://github.com/tc39/ so it can be maintained as part of the official TC39 tool suite. The other big thing we need to accomplish in the near future is to have an official html version that can be released as http://www.ecma-international.org/ecma-262/6/index.html (I may be able to get Ecma to change the last node from 6 to 2015) (See for example http://www.ecma-international.org/ecma-262/5.1/ and also see http://www.ecma-international.org/publications/standards/Ecma-262.htm and http://www.ecma-international.org/publications/standards/Ecma-262-arch.htm ) Each time a new revision is published, some manual steps are required to map broken links to the right sections in the new document. Do you mean that old 'es6-draft.html' URLs should resolve to the corresponding section in the HTML version of the latest ES7+ draft? (In which case, the latter would need to continue to support (remap) all the old section-ids.) I wonder if people would find that surprising. I hadn't considered it. Given the use cases I know about (mostly es-discuss and in implementations' bug-tracking databases), I think it's better to do it the other way, so that ES6-era links continue to point to an ES6 spec. I agree, also blog post and old tweets, etc... Starting from scratch will not save a whole lot of work, though. The work required with each revision is mostly figuring out how to redirect section-ids that were newly changed in that revision, not maintaining the old redirects (which is at most some search-and-replace). I could probably come up with a way to include permanent ids in section headings as Word invisible fields. It would be a little more work for spec. editors (and somewhat bug prone: forgetting to include one, forgetting to change the id when copying a heading, etc) but would eliminate the need to maintain an external map. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
there's actually no way, officially, to reference what ES2015 call *the global object*, just pointless fragmentation between engines. On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: So I'd say we should not have `self` (if stays on global and Worker I don't actually care) and add a `global` that nobody needs explanation to understand what it is in JavaScript Indeed, three ways to reference the global object is not nearly enough. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
`self` is a very common local variable name, usually used as a substitute of `this`. So making it a global variable is a terrible idea. Consider this: ```function blah() {} blah.prototype.foo = function () { var self = this asyncStuff(function () { self.complete = true })}``` So what happens if you forget that `var self` declaration? Right now in server-side js it's a good old reference error. But if `self` gets adopted, this code will not always fail, but will lead to mistakes (global variable named `complete` in this example). I'd much rather have "window" and "global" as is honestly. 17.04.2015, 18:02, "Boris Zbarsky" bzbar...@mit.edu:On 4/17/15 10:55 AM, Andrea Giammarchi wrote: We have `window` in DOM land, `self` in WorkersWe have `self` in DOM land too, so you can consistently use `self` across Window and Workers. and `global` in most common server side JS enginesSounds like they should add `self`. ;)-Boris___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Putting `global` reference in specs
One thing I'm surprised nobody has brought up yet is that global would be an incorrect name in the case of browsers. The actual global object is not (and must never be) directly accessible. Instead you get a window proxy when you use `window`, `self`, `this`, etc. As such I think our best bet is for server-side JS runtimes to use `self` or `window`. The latter isn't as crazy as it sounds: just start adding phrases to the ES spec like all JavaScript code runs within a certain context, called a _window_, which has a corresponding _window object_. In some runtimes the window object will be equivalent to the global object, but not always. Scripts run within _window scope_, whereas modules run in their own lexical context. The value of **this** in window scope is the window object. It's not as if `window` actually means window anymore, given tabs and iframes and frames. We might as well move it into the set of terms like realm or vat or environment that are more abstract than real. -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Anne van Kesteren Sent: Friday, April 17, 2015 11:19 To: Andrea Giammarchi Cc: es-discuss@mozilla.org Subject: Re: Putting `global` reference in specs On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: So I'd say we should not have `self` (if stays on global and Worker I don't actually care) and add a `global` that nobody needs explanation to understand what it is in JavaScript Indeed, three ways to reference the global object is not nearly enough. -- https://annevankesteren.nl/ ___ 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
Re: Putting `global` reference in specs
And that's indeed the only place on Web world where `self` makes sense: it's referring to the frame (scoped) context its running, not to the `top` (global) tab wrapper. On Fri, Apr 17, 2015 at 7:51 PM, Brendan Eich bren...@mozilla.org wrote: Just for historians who might not know, when I did ur-JS in 1995, I made multiple names for the global, in part because event handlers (which prefigured nested functions in general, and added with-like DOM object scoping -- a regret); but also in part because a target=_self was a thing in Netscape 2. /be Boris Zbarsky wrote: On 4/17/15 10:55 AM, Andrea Giammarchi wrote: We have `window` in DOM land, `self` in Workers We have `self` in DOM land too, so you can consistently use `self` across Window and Workers. and `global` in most common server side JS engines Sounds like they should add `self`. ;) -Boris ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
The principle extends just fine to workers, and has. /be Andrea Giammarchi wrote: And that's indeed the only place on Web world where `self` makes sense: ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: do while scope
Well, there's a lot of precedent I'm languages for it (the while condition) to
not be a part of the block scope. So from that prospective it's unsurprising,
though it may surprise developers accustomed to variable hosting
On Apr 17, 2015, at 11:18 AM, Glen Huang curvedm...@gmail.com wrote:
Not sure about others, but i assume the condition part and statement part in
a control construct live in the same scope.
That's why you can do `for (let a = 1; a 2; a++) a;`. And `if (let a = 1)
a;` maybe in es7?
Why that's not the case for do while? Is my mental model wrong?
On Apr 17, 2015, at 11:10 PM, Caitlin Potter caitpotte...@gmail.com wrote:
Is there a language where lexically scoped variables declared in a block are
accessible outside of that block? Java, C, C#, rust, Python, etc, will not
let you do this. I’m not sure this is a gotcha for most software developers
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com wrote:
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
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
Re: Putting `global` reference in specs
On 17 April 2015 at 17:27, Mark S. Miller erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the
global object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I
don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
also `eval` can be in-scope redefined as much as global, window, or self,
so no, that's actually not a solution.
Btw, I wasn't asking for a workaround, I was proposing to officially bring
ES 2015 `global` object as language reference in ES7/201X
It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
millions of results in Github for `typeof global` apparently got unnoticed )
On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
it's a no-go under CSP so it's as bad as `Function('return this')()`
On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/17/15 11:27 AM, Mark S. Miller wrote:
(1,eval)('use strict; this')
This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike window, self, or global) ;)
-Boris
___
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
Re: Putting `global` reference in specs
Jordan Harband wrote: Is there some reason that a Reflect function (or accessor, but I'd prefer a function for ES3 engine support) wouldn't be an option? Upthread: https://esdiscuss.org/topic/putting-global-reference-in-specs#content-16 /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
We cannot introduce a global property named `global` at this point. I don't think everyone replying lately has read the whole thread carefully :-|. /be Andrea Giammarchi wrote: Sure workers too, but it doesn't in server side and it doesn't mean anything meaningful for all developers coming from other languages. `self` is a misleading word and in ES6 specs we have mentioned global object and never a single word for the `self` keyword, or its meaning. `global` does not need that kind of explanation you put down for historical purpose, `global` is well known meaning for everyone in JS world, including members in this ML that would refer to the global scope, and the global object, regardless they mean sometimes `realm` ... or isn't it? On Fri, Apr 17, 2015 at 10:38 PM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: The principle extends just fine to workers, and has. /be Andrea Giammarchi wrote: And that's indeed the only place on Web world where `self` makes sense: ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Putting `global` reference in specs
Not so pretty but:
import * as global from “@global”;
Or some bindings:
import {Promise} from “@global”;
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark
Miller
Sent: April 17, 2015 11:53 AM
To: Glen Huang
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: Putting `global` reference in specs
This is one of several cases where, post ES6, we can provide a std module
import that provides a built-in that carries authority. Another example is the
constructor for making weak references, which necessarily provide the ability
to read a covert channel. As with shadowable globals, this module import must
be easy to virtualize. We purposely postponed this along with the Loader and
Realm API as it is security sensitive and we don't yet have enough usage
experience with modules to know how to design this separation well.
In particular, we rejected the obvious Reflect.global as it bundles the global
together with authority-free safe things, which makes virtualization of the
global alone needlessly unpleasant.
On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang
curvedm...@gmail.commailto:curvedm...@gmail.com wrote:
You guys are talking about referencing the global object in modules right?
Since in scripts you can reliably get hold of the global object by using this
in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope of a
module, I guess that means module code really isn't supposed to get hold of the
global object?
On Apr 17, 2015, at 11:34 PM, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the use strict;
makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg
rossb...@google.commailto:rossb...@google.com wrote:
On 17 April 2015 at 17:27, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the global
object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren
ann...@annevk.nlmailto:ann...@annevk.nl wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
Sure workers too, but it doesn't in server side and it doesn't mean anything meaningful for all developers coming from other languages. `self` is a misleading word and in ES6 specs we have mentioned global object and never a single word for the `self` keyword, or its meaning. `global` does not need that kind of explanation you put down for historical purpose, `global` is well known meaning for everyone in JS world, including members in this ML that would refer to the global scope, and the global object, regardless they mean sometimes `realm` ... or isn't it? On Fri, Apr 17, 2015 at 10:38 PM, Brendan Eich bren...@mozilla.org wrote: The principle extends just fine to workers, and has. /be Andrea Giammarchi wrote: And that's indeed the only place on Web world where `self` makes sense: ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
I was under the impression there'd been some interest in a `Reflect.global()` as a uniform method of providing the global object, or a proxy to one, in all engines. That would be something that's easily polyfilled back as far as we like, would allow most code that currently relies on indirect eval to work in a CSP environment (including the es6-shim), and would not impose any new global variables, nor any restrictions on global variables, on existing engines. Is there some reason that a Reflect function (or accessor, but I'd prefer a function for ES3 engine support) wouldn't be an option? On Fri, Apr 17, 2015 at 2:38 PM, Brendan Eich bren...@mozilla.org wrote: The principle extends just fine to workers, and has. /be Andrea Giammarchi wrote: And that's indeed the only place on Web world where `self` makes sense: ___ 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
