Surely this can be dealt with by extending the CSP policy to allow script
domains which are able to call System.define. Surely it is an equivalent
permission to being able to load script from the domain anyway, when it is
restricted to running in the outer scope only?
On 31 October 2013 16:10,
I think I must be missing something?
On Fri, Nov 1, 2013 at 6:47 AM, Guy Bedford guybedf...@googlemail.comwrote:
Surely this can be dealt with by extending the CSP policy to allow script
domains which are able to call System.define.
How is that different to extending the CSP policy to allow
I suppose I am hypothesising that it might be possible to limit the
invocation to the outer scope only in some CSP mode.
// allowed:
System.define(['some-module'], ['export var q = p;']);
// not allowed:
(function() {
System.define(['some-module'], ['export var q = p;']);
})();
In this way,
On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison lbljef...@gmail.com wrote:
Throwing this out there while I stew on the pros/cons of it (so others can
as well):
I wonder how terrible it would be to have this API define module bodies in
terms of a passed function that, say, accepted and/or
If we limit `module 'm' { ... }` to Script then we still keep the flat
module hierarchy.
On Nov 1, 2013 2:32 PM, James Burke jrbu...@gmail.com wrote:
On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison lbljef...@gmail.com
wrote:
Throwing this out there while I stew on the pros/cons of it (so
On 11/1/13, 11:32 AM, James Burke wrote:
On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison lbljef...@gmail.com wrote:
Throwing this out there while I stew on the pros/cons of it (so others can
as well):
I wonder how terrible it would be to have this API define module bodies in
terms of a passed
On Fri, Nov 1, 2013 at 1:04 PM, Jeff Morrison lbljef...@gmail.com wrote:
No, that's why I said the function generates an instance of a Module object
imperatively (we're already in imperative definition land with this API
anyway).
No need for `import` or `export`
My understanding is that there
On 11/1/2013 1:28 PM, James Burke wrote:
Perhaps you know how a mutable slot could be expressed using existing
syntax for creating Module objects? Illustrating how would clear up a
big disconnect for me.
If I'm understanding what you mean by mutable slot, the only way it
can be expressed
(I'm operating on the assumption that the Module constructor is still
part of the spec):
```
System.define({
A: {
deps: ['B','C'],
factory: function(B, C) {
var stuff = B.doSomething();
return new Module({stuff: stuff});
}
},
B: {
deps: ['D', 'E'],
factory:
On Fri, Nov 1, 2013 at 2:19 PM, Jeff Morrison lbljef...@gmail.com wrote:
(I'm operating on the assumption that the Module constructor is still part
of the spec):
```
System.define({
A: {
deps: ['B','C'],
factory: function(B, C) {
var stuff = B.doSomething();
return
On Oct 31, 2013, at 7:10 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
I see that Jason added a Loader.prototype.define to his reference
implementation.
https://people.mozilla.org/~jorendorff/js-loaders/Loader.html#section-177.
This is great. It is a much needed capability to allow
I see that Jason added a Loader.prototype.define to his reference
implementation.
https://people.mozilla.org/~jorendorff/js-loaders/Loader.html#section-177.
This is great. It is a much needed capability to allow bundling modules
into a single file.
It allows you to do something like
This is excellent, but I had been worried about a string/eval-based
define() API as well.
Throwing this out there while I stew on the pros/cons of it (so others
can as well):
I wonder how terrible it would be to have this API define module bodies
in terms of a passed function that, say,
13 matches
Mail list logo
