Le 20/01/2014 23:16, Kevin Reid a écrit :
SES needs to visit every 'primordial' / 'singleton' object to ensure
they're made immutable and harmless. (Other 'meta' code might also
benefit though I don't know of any examples offhand.)
This job is easier if all such objects are reachable via
On Jan 20, 2014, at 11:46 PM, Andy Wingo wrote:
On Mon 20 Jan 2014 18:39, Brendan Eich bren...@mozilla.com writes:
Allen Wirfs-Brock wrote:
It isn't clear that there much need for a global name for
GeneratorFunction. If you really eed to access it can always get it
via:
(function
On Jan 20, 2014, at 2:16 PM, Kevin Reid wrote:
On Sun, Jan 19, 2014 at 7:21 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
It isn't clear that there much need for a global name for GeneratorFunction.
If you really eed to access it can always get it via:
(function *()
Allen Wirfs-Brock wrote:
It isn't clear that there much need for a global name for
GeneratorFunction. If you really eed to access it can always get it via:
(function *() {}).constructor
Does this present a hazard for CSP, which provides policy controls
governing Function?
I agree we
It seem strangely inconsistent not to make it a global. I've had to access
GeneratorFunction using the aforementioned method when I was writing an
async view engine to dynamically create rendering functions like so:
var GeneratorFunction = (function *() {}).constructor;
var functionBody =
Le 20/01/2014 18:39, Brendan Eich a écrit :
Allen Wirfs-Brock wrote:
It isn't clear that there much need for a global name for
GeneratorFunction. If you really eed to access it can always get it
via:
(function *() {}).constructor
Do we even need (function *() {}).constructor !==
On Jan 20, 2014, at 9:39 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
It isn't clear that there much need for a global name for GeneratorFunction.
If you really eed to access it can always get it via:
(function *() {}).constructor
Does this present a hazard for CSP, which
On Sun, Jan 19, 2014 at 7:21 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
It isn't clear that there much need for a global name for
GeneratorFunction. If you really eed to access it can always get it via:
(function *() {}).constructor
(as the always helful generator UMO diagram at
On Mon 20 Jan 2014 18:39, Brendan Eich bren...@mozilla.com writes:
Allen Wirfs-Brock wrote:
It isn't clear that there much need for a global name for
GeneratorFunction. If you really eed to access it can always get it
via:
(function *() {}).constructor
Does this present a hazard for
I'm inclined to say this has missed the train for ES6.
That may be fine. It seems like we would use a little more experience with ES6
modules before we tackle this.
Allen
On Jan 19, 2014, at 8:47 AM, Tom Van Cutsem wrote:
I don't know of a more current one, but things have probably
I'm inclined to say this has missed the train for ES6.
That may be fine. It seems like we would use a little more experience
with ES6 modules before we tackle this.
Definitely. It appears that the only thing in the ES6 draft which mentions
standard modules is GeneratorFunction. Will that
That makes sense. I guess the only things that would be missed are `values()`,
`entries()` and possibly `keys()` (if works works differently from
Object.keys()) from module @dict. At the very least, an `Object.entries()`
should be introduced if we don’t get that module.
Polyfilling and trying
On Jan 19, 2014, at 6:03 PM, Kevin Smith wrote:
I'm inclined to say this has missed the train for ES6.
That may be fine. It seems like we would use a little more experience with
ES6 modules before we tackle this.
Definitely. It appears that the only thing in the ES6 draft which
We think static checking for unbound variables is valuable, and
letting people write `console.log` without having to import anything
is valuable. Thus, option 3.
Another option would be to check unbound variables not in the linking
phase, but immediately before executing the module body.
Not sure how to answer your question exactly, James, but the takeaway is
that under the current design, it is not sufficient to import
global-object polyfills from the module that uses the polyfills. Global
object polyfills must be loaded in a *prior* compilation/execution cycle.
Bascially,
On Jun 20, 2013 7:53 PM, James Burke jrbu...@gmail.com wrote:
On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith zenpars...@gmail.com
wrote:
I wonder, though, if this might create issues for polyfilling:
//
I would think the advantage of running compile-time checks against the
global object is that it can catch errors that we currently use linters for:
// OOPS - forgot this line!
// import { x } from foo;
function someRareCase() {
x(); // Reference error?
}
That's useful,
On Thu, Jun 20, 2013 at 9:55 AM, Kevin Smith zenpars...@gmail.com wrote:
I would think the advantage of running compile-time checks against the
global object is that it can catch errors that we currently use linters for:
// OOPS - forgot this line!
// import { x } from foo;
This actually is the sort of thing that can be difficult to check for
off-line linters, because the use of global variables may depend on
some staged dynamic configuration that a linter cannot easily see,
verify, or assume.
That's pretty much true for everything about javascript : )
In my
We think static checking for unbound variables is valuable, and
letting people write `console.log` without having to import anything
is valuable. Thus, option 3.
I think that's fine, if we're willing to discourage dynamic usage of the
global object for unbound variables. Static checking of
I wonder, though, if this might create issues for polyfilling:
// polyfillz.js
if (this.Promise === void 0)
this.Promise = function() { ... }
// main.js
import polyfillz.js;
new Promise();
This would refuse to compile, right? We'd have to introduce all of our
On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith zenpars...@gmail.com wrote:
I wonder, though, if this might create issues for polyfilling:
// polyfillz.js
if (this.Promise === void 0)
this.Promise = function() { ... }
// main.js
import polyfillz.js;
new
Yes, like so:
script src=polyfillz.js/
Sure. In a server environment, you'd have to do your monkey-patching and
then load your main module dynamically through the loader api.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith zenpars...@gmail.com wrote:
I wonder, though, if this might create issues for polyfilling:
// polyfillz.js
if (this.Promise === void 0)
this.Promise =
On Tue, Jun 18, 2013 at 11:29 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Sam Tobin-Hochstadt
This is close, but not quite right. The rule is that any unbound variables
in modules are errors. The variables may be bound by import declarations,
or by lexical bindings such
But a compile-time error as Domenic is wondering? That doesn't seem quite
right to me. I would think that those would be runtime errors (as is the
case in strict-mode). Otherwise this is a big semantic change that I
haven't previously considered.
{ Kevin }
First, I meant what I said in my previous email -- that program is a
compile time error inside a module.
Second, the meaning of that program doesn't change in strict mode. If
the reference is evaluated before the assignment, it's a
ReferenceError even in non-strict mode. If the assignment is
OK - I see it on the wiki here:
Compilation resolves and validates all variable definitions and references
It still seems odd to me that we're going to check a dynamic object (the
global object) at link-time for references. What if the global object is
changed after the linking pass, but before
On Wed, Jun 19, 2013 at 11:37 AM, Kevin Smith zenpars...@gmail.com wrote:
OK - I see it on the wiki here:
Compilation resolves and validates all variable definitions and references
It still seems odd to me that we're going to check a dynamic object (the
global object) at link-time for
Note that there are situations where you can still get a
ReferenceError inside a module, by deleting properties off of
`window`. Ruling this out would require:
1. not giving modules access to the global scope, or
2. changing the global object when compiling modules
Neither of these seem
From: Sam Tobin-Hochstadt
This is close, but not quite right. The rule is that any unbound variables
in modules are errors. The variables may be bound by import declarations, or
by lexical bindings such as `var` or `let`, or by bindings on the global
object, or by top-level `let`
On Sat, Jun 8, 2013 at 5:08 AM, Brian Di Palma off...@gmail.com wrote:
The standard modules wiki page (
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard ) is
not clear as to whether what it describes is a concrete proposal and
that ES6 will include it or it's purely a concept.
Good, I like the standard modules idea.
On Sat, Jun 8, 2013 at 2:33 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
The global object will still be accessible in modules. Of course, you
can create new module loaders with an empty global.
Umm. It makes porting old code easier.
If we could
On Sat, Jun 8, 2013 at 2:00 PM, Brian Di Palma off...@gmail.com wrote:
Good, I like the standard modules idea.
On Sat, Jun 8, 2013 at 2:33 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
The global object will still be accessible in modules. Of course, you
can create new module loaders
On Sat, Jun 8, 2013 at 7:07 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
I think you misunderstand. The requirement that modules not have free
variables at compile time *includes* global references. I expect that
development environments won't have a problem handling this or
enforcing
On Sat, Jun 8, 2013 at 2:30 PM, Brian Di Palma off...@gmail.com wrote:
On Sat, Jun 8, 2013 at 7:07 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
I think you misunderstand. The requirement that modules not have free
variables at compile time *includes* global references. I expect that
36 matches
Mail list logo
