Re: Putting `global` reference in specs
at this point you mean it will never be introduced, not even as alias in ES7 or ES8, do I understand correctly? Best Regards On Sat, Apr 18, 2015 at 5:17 AM, Brendan Eich bren...@mozilla.org wrote: 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
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
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: 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: 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: 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: 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
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: 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: 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: 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: 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
