System.import FTW
Can someone point me to the spec for `System.import`?
https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
doesn't seem to include it.
It seems to me that it would be worthwhile to ensure that
`System.import` had good semantics. It would allow a nice migration
path for existing AMD and node-style modules. For example:
```js
// AMD-style define!
// (Promise.map and Promise.spread would be nice here; see
// https://github.com/cscott/prfun)
function define(deps, f) {
return Promise.all(deps.map(d = System.import(d)))
.then( (...args) = f(...args) )
.then( registerModule )
}
```
and
```js
// Node-style require needs more magic.
Promise.async(function*() {
/* start module text */
var fs = yield System.import('fs');
// etc.
/* end module text */
return module.exports;
}).then( registerModule );
```
But that implies that `System.import` has well defined cycle-breaking,
extensibility, etc. Could it?
--scott
ps. https://gist.github.com/wycats/51c96e3adcdb3a68cbc3/#comment-1006744
--
( http://cscott.net/ )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
On 14 February 2014 14:13, C. Scott Ananian ecmascr...@cscott.net wrote:
Can someone point me to the spec for `System.import`?
It's in the ES6 specification draft under Loader.prototype.import -
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-loader.prototype.import
.
https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
doesn't seem to include it.
It seems to me that it would be worthwhile to ensure that
`System.import` had good semantics. It would allow a nice migration
path for existing AMD and node-style modules. For example:
```js
// AMD-style define!
// (Promise.map and Promise.spread would be nice here; see
// https://github.com/cscott/prfun)
function define(deps, f) {
return Promise.all(deps.map(d = System.import(d)))
.then( (...args) = f(...args) )
.then( registerModule )
}
```
This is not the recommended way to register a module - rather this is what
Dynamic Instantiation is designed to handle for you, so there is no need to
work out how to link the dependencies manually. See
https://gist.github.com/dherman/7568080 or the outdated (using old syntax,
but the principles remain) essay
https://gist.github.com/wycats/51c96e3adcdb3a68cbc3 for more info.
and
```js
// Node-style require needs more magic.
Promise.async(function*() {
/* start module text */
var fs = yield System.import('fs');
// etc.
/* end module text */
return module.exports;
}).then( registerModule );
```
Again, this is solved by dynamic instantiation.
But that implies that `System.import` has well defined cycle-breaking,
extensibility, etc. Could it?
--scott
ps. https://gist.github.com/wycats/51c96e3adcdb3a68cbc3/#comment-1006744
--
( http://cscott.net/ )
___
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: System.import FTW
Thanks. I was missing the relationship between System and Loader somehow. So System.import is intended to be exactly the same as the import keyword (except promise-returning). That's good! Is there a way to do without the export keyword as well (I've heard rumors of anonymous exports but haven't named to track down a spec)? If so, it seems like as ES5 shim (not a full polyfill) could enable module authors to start tying into ES6 modules without corrupting their source with new keywords. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net wrote: Thanks. I was missing the relationship between System and Loader somehow. So System.import is intended to be exactly the same as the import keyword (except promise-returning). There is a big difference here. The syntax for import normalizes the name and then resolves the name relative to the current module. System.import only takes an already normalized name relative to the baseURL. So, you need to do the normalization and resolviong manually first. There was a proposal to have import do the normalizing and also take an optional referrerName. I'm afraid I don't remember what the outcome of that was. That's good! Is there a way to do without the export keyword as well (I've heard rumors of anonymous exports but haven't named to track down a spec)? There is a default export. It is just syntactic sugar over exporting and importing something with the name `default`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
(There is no spec on System, just rumors that it will be a predefined,
global instance of Loader).
As far I know the only way to use the es6 module loader without exports or
imports is to set values on 'this', the global object. I guess it's not
very different from using IIFE (function() { this.foo = 2; })(); vs a
module containing the body of the function.
On Fri, Feb 14, 2014 at 11:57 AM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning).
There is a big difference here. The syntax for import normalizes the name
and then resolves the name relative to the current module. System.import
only takes an already normalized name relative to the baseURL. So, you need
to do the normalization and resolviong manually first. There was a proposal
to have import do the normalizing and also take an optional referrerName.
I'm afraid I don't remember what the outcome of that was.
That's good! Is there a way to do without the export keyword as well
(I've heard rumors of anonymous exports but haven't named to track down a
spec)?
There is a default export. It is just syntactic sugar over exporting and
importing something with the name `default`.
___
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: System.import FTW
erik: I'd be interested in learning the outcome of the normalization
discussion. As one of the maintainers of es6-shim I'm particularly
interested in ways to access ES6 features with ES5 syntax. If that
looks like:
```js
this['default'] = Promise.join(System.import('foo'),
System.import('bar')).spread(function(foo, bar) {
return { ... exports ... };
});
```
I can live with that. Any chance that we will accept and unwrap a
promise for the exported value? (Not that it really matters for the
above, since Promise.join will do recursive unwrapping, but it would
be nice for compatibility if this were transparent in general.)
john: yes, I suspected that System was underspecified. That's too bad.
--scott
On Fri, Feb 14, 2014 at 9:57 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning).
There is a big difference here. The syntax for import normalizes the name
and then resolves the name relative to the current module. System.import
only takes an already normalized name relative to the baseURL. So, you need
to do the normalization and resolviong manually first. There was a proposal
to have import do the normalizing and also take an optional referrerName.
I'm afraid I don't remember what the outcome of that was.
That's good! Is there a way to do without the export keyword as well
(I've heard rumors of anonymous exports but haven't named to track down a
spec)?
There is a default export. It is just syntactic sugar over exporting and
importing something with the name `default`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
On Feb 14, 2014, at 12:09 PM, John Barton johnjbar...@google.com wrote: (There is no spec on System, just rumors that it will be a predefined, global instance of Loader). Rumors is a bit much. :) The notes do show the discussion but the resolution for some reason didn't get recorded. IIRC there was agreement that Reflect and System will both be globals (this has also been the general understanding for a long time, so it's nothing new). https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
On Fri, Feb 14, 2014 at 12:59 PM, David Herman dher...@mozilla.com wrote: https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update Yeah, I read that, and I thought the absence of a 'Resolution' was a bit suspicious. I thought there was a strong argument to export only one additional global, `Loader`, and to make the-instance-formerly-known-as-System available via `Loader`. I don't have a particular opinion here, but I will note that Java has a `System` class with very different semantics, so there may be some mental variable shadowing for some developers. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
I don't think the details in System will be important, as you suggest there is not much to say. The critical issue is whether we will have access to an ES6 specified Loader class. The Loader class and System.fetch is enough I think to do any custom loader thing one wants. If we only have System then our customization options will be limited since we won't be able to call super methods. On Fri, Feb 14, 2014 at 2:59 PM, David Herman dher...@mozilla.com wrote: On Feb 14, 2014, at 12:09 PM, John Barton johnjbar...@google.com wrote: (There is no spec on System, just rumors that it will be a predefined, global instance of Loader). Rumors is a bit much. :) The notes do show the discussion but the resolution for some reason didn't get recorded. IIRC there was agreement that Reflect and System will both be globals (this has also been the general understanding for a long time, so it's nothing new). https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
