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
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
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
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.
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
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
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
-
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
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
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
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
, 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
(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
, 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
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,
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
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`
-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
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
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
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
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
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
`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
@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
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
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
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
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
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
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
: 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
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
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
34 matches
Mail list logo
