Re: Standard modules?
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 https://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. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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 *() {}).constructor
Does this present a hazard for CSP, which provides policy controls
governing Function?
Relevant spec:
http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#script-src
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.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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 *() {}).constructor
(as the always helful generator UMO diagram at
http://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.
https://code.google.com/p/google-caja/issues/detail?id=1661
https://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.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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.
On Tue, Jan 21, 2014 at 4:39 AM, Brendan Eich bren...@mozilla.com 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 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.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sebastian McKenzie
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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 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
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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
http://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.
https://code.google.com/p/google-caja/issues/detail?id=1661
https://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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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 CSP, which provides policy controls
governing Function?
Relevant spec:
http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#script-src
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.
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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 changed since nov. 2012 (the page's last edit). For instance, Proxy now lives in a separate @reflect module. Regards, Tom 2014/1/19 Axel Rauschmayer a...@rauschma.de http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard Is this the most current document on the standard modules? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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. Axel On Jan 20, 2014, at 2:48 , Allen Wirfs-Brock al...@wirfs-brock.com 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. 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 changed since nov. 2012 (the page's last edit). For instance, Proxy now lives in a separate @reflect module. Regards, Tom 2014/1/19 Axel Rauschmayer a...@rauschma.de http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard Is this the most current document on the standard modules? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
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 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
http://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___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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. That would give
us the advantage of variable checks, but also allow more flexibility when
polyfilling or otherwise tweaking the global object.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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, you'll have to somehow (a) setup your global object with
polyfills, and then (b) load your main module, with (a) and (b) happening
in separate stages.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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:
// 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
polyfills in a separate (previous) compilation/execution cycle.
Yes, like so:
script src=polyfillz.js/
Note that this is already the way people suggest using polyfills; see
[1] for an example.
I have found that once I have module loading, I want the dependencies
to be specified by the modules that use them, either via the
declarative dependency syntax or via module loader APIs, and at the
very least, avoid script tags as the optimization tools can work
solely by tracing module/JS loading APIs. In this case, only the
model set of modules would care about setting up indexeddb access,
not the top level of the app.
Example, this AMD module:
https://github.com/jrburke/carmino/blob/master/www/lib/IDB.js
Asks for indexedDB!, which is an AMD loader plugin:
https://github.com/jrburke/carmino/blob/master/www/lib/indexedDB.js
which feature detects and uses a module loader API to load a shim if
it is needed. So the IDB module will not execute until that optional
shim work is done.
I believe this will also work via the ES Module Loader API, but
calling it out just in case I missed something. I want to be sure
there are options that do not require using script src tags, except
maybe one to bootstrap a set of Module Loader hooks.
Yes, this will work fine. Loader hooks can explicitly add modules using the
loader API, allowing them to polyfill in exactly this way.
Sam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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, but it comes at the price of treating the global object as
if it were a static thing, and not dynamic. From my point of view, though,
a dynamic global object is just how it goes with Javascript. I think this
kind of static checking should be left to linters, unless we are adopting a
policy of actively discouraging dynamism for the global object.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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;
function someRareCase() {
x(); // Reference error?
}
That's useful, but it comes at the price of treating the global object as if
it were a static thing, and not dynamic. From my point of view, though, a
dynamic global object is just how it goes with Javascript. I think this
kind of static checking should be left to linters, unless we are adopting a
policy of actively discouraging dynamism for the global object.
We could:
1. Give up on static checking of unbound variables in modules.
2. Take the global object off the scope chain in modules.
3. Adopt a compromise.
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.
Sam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 usage of linters for this task (using my own linters of course), I
would have a predefined set of global variables that are allowed -
essentially treating the global object as if it were static for the
purposes of linting.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 the global object
might create some iffy edge cases for users who want to treat the global
object as a more dynamic thing.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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
polyfills in a separate (previous) compilation/execution cycle.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 Promise();
This would refuse to compile, right? We'd have to introduce all of our
polyfills in a separate (previous) compilation/execution cycle.
Yes, like so:
script src=polyfillz.js/
Note that this is already the way people suggest using polyfills; see
[1] for an example.
Sam
[1] https://github.com/axemclion/IndexedDBShim
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 = function() { ... }
// main.js
import polyfillz.js;
new Promise();
This would refuse to compile, right? We'd have to introduce all of our
polyfills in a separate (previous) compilation/execution cycle.
Yes, like so:
script src=polyfillz.js/
Note that this is already the way people suggest using polyfills; see
[1] for an example.
I have found that once I have module loading, I want the dependencies
to be specified by the modules that use them, either via the
declarative dependency syntax or via module loader APIs, and at the
very least, avoid script tags as the optimization tools can work
solely by tracing module/JS loading APIs. In this case, only the
model set of modules would care about setting up indexeddb access,
not the top level of the app.
Example, this AMD module:
https://github.com/jrburke/carmino/blob/master/www/lib/IDB.js
Asks for indexedDB!, which is an AMD loader plugin:
https://github.com/jrburke/carmino/blob/master/www/lib/indexedDB.js
which feature detects and uses a module loader API to load a shim if
it is needed. So the IDB module will not execute until that optional
shim work is done.
I believe this will also work via the ES Module Loader API, but
calling it out just in case I missed something. I want to be sure
there are options that do not require using script src tags, except
maybe one to bootstrap a set of Module Loader hooks.
James
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 as `var` or `let`, or by bindings on the global object, or by top-level `let` bindings (which are not on the global object, IIRC). Is this correct then? Yes, the below is all correct. Sam ```js Date.now(); ``` is checked at compile time and found to be OK, because it is referencing a binding that is a property of the global object that exists at the time of static-checking. But ```js setTimeout(() = asdf(); // (A) }, 5000); setTimeout(() = window.asdf = () =; // (B) }, 1000); ``` is checked at compile time and found to *error*, because (A) is referencing a binding that is a not a property of the global object at the time of static checking? (Assuming an `asdf` binding is not introduced through any of the other mechanisms you mention.) And this is true even though (B) adds such a property to the global object before (A) ever runs? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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
evaluated first, it will work even in strict mode.
Sam
On Wed, Jun 19, 2013 at 9:53 AM, Kevin Smith zenpars...@gmail.com wrote:
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 }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 the module executes? Does the
variable reference still point to the old thing?
// Before linking, window.bar = before
// foo.js
bar = after;
// main.js
import foo;
console.log(bar); // before?
Thanks,
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 references. What if the global object is changed after the linking pass, but before the module executes? Does the variable reference still point to the old thing? // Before linking, window.bar = before // foo.js bar = after; // main.js import foo; console.log(bar); // before? This produces after -- mutable variables are still mutable. Saving an old version would be pretty strange. 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 like good ideas. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 like good ideas.
I agree. I wonder, though, why my previous example should work, but this
should fail:
// Before linking, window.bar is not defined
// foo.js
window.bar = bar;
// main.js
import foo;
console.log(bar); // Link time error
But if we ran foo in a previous linking/execution pass, then it would
work.
Since this is a departure from the current non-module handling of global
object variable references, what is the motivation?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Standard modules - concept or concrete?
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` bindings (which are not on the global object, IIRC). Is this correct then? ```js Date.now(); ``` is checked at compile time and found to be OK, because it is referencing a binding that is a property of the global object that exists at the time of static-checking. But ```js setTimeout(() = asdf(); // (A) }, 5000); setTimeout(() = window.asdf = () =; // (B) }, 1000); ``` is checked at compile time and found to *error*, because (A) is referencing a binding that is a not a property of the global object at the time of static checking? (Assuming an `asdf` binding is not introduced through any of the other mechanisms you mention.) And this is true even though (B) adds such a property to the global object before (A) ever runs? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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. ES6 will definitely provide some set of standard modules. The primary open questions are (a) what will the modules be named and (b) how fine-grained will the module split be. Is this a prerequisite for static checks in modules ( forbid all globals in modules unless explicitly imported )? I'm sure the checks aren't as harsh, but I'd love such strictness as it can make tooling more powerful and code simpler to understand and follow. The idea that you can grab anything from the global object without first importing it seems wrong. The global object will still be accessible in modules. Of course, you can create new module loaders with an empty global. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 guarantee that any reference inside a module had to have
an import definition I imagine IDEs and development concatenation
tools would provide
fast feedback when those rules are broken. Why would people use the
standard modules if they can just access the global?
Is it expected that developers import things like Date because it
would be good practice?
import { Date } from @std;
or simply
new Date();
I can imagine many people just taking option 2. Seem to make standard
modules somewhat redundant, or at least it undermines them.
I suppose then the static checks are only to check that a module
imports the identifiers that another module exports, is that it?
If we can grab anything from the global that means un-imported
references can be used all over module code and the environment will
just have
to shrug its shoulders an accept it. No compile time error. Somewhat
disappointed with that.
So modules will be allowed to be polluted by the global state, not
just build in globals but any possible user defined global state.
The possibility of strengthening module consistency is off the table?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 with an empty global.
Umm. It makes porting old code easier.
If we could guarantee that any reference inside a module had to have
an import definition I imagine IDEs and development concatenation
tools would provide
fast feedback when those rules are broken. Why would people use the
standard modules if they can just access the global?
Is it expected that developers import things like Date because it
would be good practice?
import { Date } from @std;
or simply
new Date();
I can imagine many people just taking option 2. Seem to make standard
modules somewhat redundant, or at least it undermines them.
I suppose then the static checks are only to check that a module
imports the identifiers that another module exports, is that it?
If we can grab anything from the global that means un-imported
references can be used all over module code and the environment will
just have
to shrug its shoulders an accept it. No compile time error. Somewhat
disappointed with that.
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 whatever properties you're looking for.
So modules will be allowed to be polluted by the global state, not
just build in globals but any possible user defined global state.
The possibility of strengthening module consistency is off the table?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 whatever properties you're looking for.
I think I see what you're saying. Let me just see if I'm correct.
At compile time any references in a module which are not explicitly
imported but are language globals will not cause compile errors.
Any references which aren't explicitly imported and aren't language
globals will cause a compile error?
So
module test {
new Date();
}
is fine.
While
module test2 {
$
}
will throw an error unless you add the line
import $ from jquery;
even if jQuery was available in the global scope and had been loaded
in by a normal script tag?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules - concept or concrete?
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 development environments won't have a problem handling this or enforcing whatever properties you're looking for. I think I see what you're saying. Let me just see if I'm correct. At compile time any references in a module which are not explicitly imported but are language globals will not cause compile errors. Any references which aren't explicitly imported and aren't language globals will cause a compile error? 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` bindings (which are not on the global object, IIRC). Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
