Standard modules?
I don't know of a more current one, but things have probably changed since nov. 2012 (the page's last edit). For instance, Proxy now lives in a separate @reflect module.
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 be specified as a property of the global object in the next draft?
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 out standard library modules should be easy enough in ES6. The module loader seems ready for resolving standard module IDs differently.
On Jan 19, 2014, at 6:03 PM, Kevin Smith wrote:
Definitely. It appears that the only thing in the ES6 draft which mentions standard modules is GeneratorFunction. Will that be specified as a property of the global object in the next draft
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 people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorfunction-objects tells us)
The two names that I think are still up in the air (as to whether they are globals) are Realm and Loader
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 shouldn't add a global GeneratorFunction -- not without a pressing use-case and evidence that we can get away with adding that global.
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 = "";
// parse view
return new GeneratorFunction(functionBody);
Accessing it via the constructor seems very sloppy.
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 !== Function?
(and [[FunctionKind]] "generator" and a different @@toStringTag and...)
What is its use case anyway? Creating a generator from source?
What's wrong with:
eval("function*(x, y, z, ...yo){/*body*/}")
(and when the source isn't trusted, use indirect eval or soon enough the module loader)
Does this present a hazard for CSP, which provides policy controls governing Function?
It introduces something that probably should be disabled by default and re-enabled only if the unsafe-eval "origin" is present. From a security perspective, note that this is a marginal (non-existent) protection and the underlying capability (executing arbitrary code) remains since an attacker can download a JS interpreter to eval any string itself.
On Jan 20, 2014, at 9:39 AM, Brendan Eich wrote:
Does this present a hazard for CSP, which provides policy controls governing Function?
Does CSP deal with (function(){}).constructor ?
CSP probably does needs to deal with this, as well as user defined subclasses of function (that super call the Function constructor).
Also assorted new ways of compiling/evaluating code from strings introduced by Module Loaders
On Sun, Jan 19, 2014 at 7:21 PM, Allen Wirfs-Brock <allen at 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 *() {}).constructor(as the always helful generator UMO diagram at people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorfunction-objects tells us)
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 traversing data properties.
ES5 contains only one object which this is not true of: [[ThrowTypeError]]. This would have been fine since [[ThrowTypeError]] as specified is immutable and harmless, but in practice many implementations have bugs or extensions which make it mutable. We had to add a special case for it to ensure that it was traversed. code.google.com/p/google-caja/issues/detail?id=1661, codereview.appspot.com/8093043/diff/19001/src/com/google/caja/ses/repairES5.js
It would be nice if there was some way in ES6 to make sure SES doesn't miss any objects — either that every primordial object is reachable via data properties (more precisely: that there are no preexisting objects which are reachable only by way of executing some program construct; e.g. Array is reachable by [].constructor, but is also named Array in the standard environment), or there is some other way to enumerate them.
David Bruant wrote:
Do we even need
(function *() {}).constructor !== Function? (and [[FunctionKind]] "generator" and a different @@toStringTag and...) What is its use case anyway? Creating a generator from source? What's wrong with:eval("function*(x, y, z, ...yo){/*body*/}")(and when the source isn't trusted, use indirect eval or soon enough the module loader)
Good questions.
On Mon 20 Jan 2014 18:39, Brendan Eich <brendan at mozilla.com> writes:
Does this present a hazard for CSP, which provides policy controls governing Function?
I guess CSP needs to be updated to have similar language for GeneratorFunction as for Function. As Allen mentions, though it doesn't have a name it is accessible.
I just took a look at SM and V8 and it seems both of them respect CSP for the GeneratorFunction constructor, though both are lacking test cases. Not sure how to trigger such a test case without a browser.
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 traversing data properties.
ES5 contains only one object which this is not true of:
Beware, I've heard that the browser contains many more of these objects. See discussion starting at bugzilla.mozilla.org/show_bug.cgi?id=900034#c4 In a nutshell, WebIDL defines the "NoInterfaceObject" which, when reified in ECMAScript means that a prototype object exists, but it can't be found via <Interface>.prototype (since <Interface> is not defined as a global). I imagine the only way to find these is create an instance and the Object.getPrototypeOf. It's apparently used in WebGL sometimes. I imagine there is a complete repository of WebIDL files somewhere (Moz/Blink codebase, maybe W3C, maybe alongside the WebGL spec) you can use to list all of these interfaces. How to create the different instances is another story.
On Jan 20, 2014, at 11:46 PM, Andy Wingo wrote:
I guess CSP needs to be updated to have similar language for GeneratorFunction as for Function. As Allen mentions, though it doesn't have a name it is accessible.
I just took a look at SM and V8 and it seems both of them respect CSP for the GeneratorFunction constructor, though both are lacking test cases. Not sure how to trigger such a test case without a browser.
I would assume that the actual test would normally be done at the level of the implementation that compiles (or executes) such code and not in the public API that exposes that capability.
On Jan 20, 2014, at 2:16 PM, Kevin Reid wrote:
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 traversing data properties.
ES5 contains only one object which this is not true of: [[ThrowTypeError]]. This would have been fine since [[ThrowTypeError]] as specified is immutable and harmless, but in practice many implementations have bugs or extensions which make it mutable. We had to add a special case for it to ensure that it was traversed. code.google.com/p/google-caja/issues/detail?id=1661, codereview.appspot.com/8093043/diff/19001/src/com/google/caja/ses/repairES5.js
It would be nice if there was some way in ES6 to make sure SES doesn't miss any objects — either that every primordial object is reachable via data properties (more precisely: that there are no preexisting objects which are reachable only by way of executing some program construct; e.g. Array is reachable by [].constructor, but is also named Array in the standard environment), or there is some other way to enumerate them.
In ES6 there are more things like [[ThrowTypeError]] including a number lintroduced in support of promises and modules. I'm seriously thinking that they should be defined as being immutable.
All intrinsics (the ES6 term for "primordials") are/will be enumerated in the ES6 spec.
I assume that in the ES6 context that SES would use Realms and module loaders to implement its sandbox so you should probably follow those spec. to make sure they do what you need.
harmony:modules_standard
Is this the most current document on the standard modules?