Re: Re: Quantifying Default Exports
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma off...@gmail.com wrote:
When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports` default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules inside
projects written using ES6 modules should be treated as modules that default
export an object. CJS modules don't have the same static semantics as their ES6
counterpart, so they should be treated as mutable objects. An ES6 Loader would
do the same when loading CJS modules.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma off...@gmail.com wrote:
When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports` default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules inside
projects written using ES6 modules should be treated as modules that default
export an object. CJS modules don't have the same static semantics as their
ES6 counterpart, so they should be treated as mutable objects. An ES6 Loader
would do the same when loading CJS modules.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to if a
CJS module imports an ES6 module that has a key named default, what should
the default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com wrote:
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma off...@gmail.com
wrote:
When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports` default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules inside
projects written using ES6 modules should be treated as modules that
default export an object. CJS modules don't have the same static semantics
as their ES6 counterpart, so they should be treated as mutable objects. An
ES6 Loader would do the same when loading CJS modules.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module` form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to if a CJS
module imports an ES6 module that has a key named default, what should the
default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com wrote:
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma off...@gmail.com
wrote:
When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports` default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules inside
projects written using ES6 modules should be treated as modules that
default
export an object. CJS modules don't have the same static semantics as their
ES6 counterpart, so they should be treated as mutable objects. An ES6
Loader
would do the same when loading CJS modules.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
that won't help if module.exports is a function
Overall the import/exports semantics of es6 and cjs modules would be
compatible if mixing named and default exports was prohibited, but the
ability to have both is hard to represent in cjs modules.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma off...@gmail.com wrote:
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module` form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to if
a CJS
module imports an ES6 module that has a key named default, what should
the
default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com
wrote:
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma off...@gmail.com
wrote:
When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports` default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules
inside
projects written using ES6 modules should be treated as modules that
default
export an object. CJS modules don't have the same static semantics as
their
ES6 counterpart, so they should be treated as mutable objects. An ES6
Loader
would do the same when loading CJS modules.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
-Calvin W. Metcalf
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs modules would be
compatible if mixing named and default exports was prohibited, but the
ability to have both is hard to represent in cjs modules.
Don't understand this, do you have some code examples? I can't see why
that would be the case.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma off...@gmail.com wrote:
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module` form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to if a
CJS
module imports an ES6 module that has a key named default, what should
the
default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com
wrote:
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
off...@gmail.com
wrote:
When an npm package exports a named identifier it's trivial to use
it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports`
default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules
inside
projects written using ES6 modules should be treated as modules that
default
export an object. CJS modules don't have the same static semantics as
their
ES6 counterpart, so they should be treated as mutable objects. An ES6
Loader
would do the same when loading CJS modules.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
-Calvin W. Metcalf
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module, importing the
first one is easy, but when importing the second one slightly less so, how
should the loader treat that default export, a easy solution for this case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and named
exports like the example at http://jsmodules.io/ which can be sumerized as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way to access
the named exports.
So in that case it would make more sense to treat default as just another
export name. But if we do that then that means that if we go back to our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean that you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs modules would be
compatible if mixing named and default exports was prohibited, but the
ability to have both is hard to represent in cjs modules.
Don't understand this, do you have some code examples? I can't see why
that would be the case.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma off...@gmail.com
wrote:
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module` form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to
if a
CJS
module imports an ES6 module that has a key named default, what should
the
default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com
wrote:
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
off...@gmail.com
wrote:
When an npm package exports a named identifier it's trivial to use
it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports`
default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules
inside
projects written using ES6 modules should be treated as modules
that
default
export an object. CJS modules don't have the same static semantics
as
their
ES6 counterpart, so they should be treated as mutable objects. An
ES6
Loader
would do the same when loading CJS modules.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
-Calvin W. Metcalf
--
-Calvin W. Metcalf
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
Making named and default exports be mutually exclusive would mean that you could treat default export like module.exports. Or just drain the swamp and remove default exports, rather than fighting these alligators. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module, importing the
first one is easy, but when importing the second one slightly less so, how
should the loader treat that default export, a easy solution for this case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and named
exports like the example at http://jsmodules.io/ which can be sumerized as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way to access
the named exports.
As mentioned in the GitHub issue I don't see why you couldn't compile to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
So in that case it would make more sense to treat default as just another
export name. But if we do that then that means that if we go back to our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean that you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs modules would be
compatible if mixing named and default exports was prohibited, but the
ability to have both is hard to represent in cjs modules.
Don't understand this, do you have some code examples? I can't see why
that would be the case.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma off...@gmail.com
wrote:
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module` form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to
if a
CJS
module imports an ES6 module that has a key named default, what
should
the
default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com
wrote:
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
off...@gmail.com
wrote:
When an npm package exports a named identifier it's trivial to
use
it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports`
default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules
inside
projects written using ES6 modules should be treated as modules
that
default
export an object. CJS modules don't have the same static semantics
as
their
ES6 counterpart, so they should be treated as mutable objects. An
ES6
Loader
would do the same when loading CJS modules.
Juan
___
es-discuss
Re: Re: Quantifying Default Exports
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method named
helper or, more likely, the named export is something like call or bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module, importing
the
first one is easy, but when importing the second one slightly less so,
how
should the loader treat that default export, a easy solution for this
case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and named
exports like the example at http://jsmodules.io/ which can be sumerized
as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way to
access
the named exports.
As mentioned in the GitHub issue I don't see why you couldn't compile to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
So in that case it would make more sense to treat default as just another
export name. But if we do that then that means that if we go back to our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another
commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean that
you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs modules would be
compatible if mixing named and default exports was prohibited, but the
ability to have both is hard to represent in cjs modules.
Don't understand this, do you have some code examples? I can't see why
that would be the case.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma off...@gmail.com
wrote:
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module` form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down
to
if a
CJS
module imports an ES6 module that has a key named default, what
should
the
default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com
wrote:
It's using traceur and building the modules to CJS, the project
uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
off...@gmail.com
wrote:
When an npm package exports a named identifier it's trivial to
use
it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports`
default
exports provide no help at all.
This sounds like an issue in your
Re: Re: Quantifying Default Exports
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method named
helper or, more likely, the named export is something like call or bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module, importing
the
first one is easy, but when importing the second one slightly less so,
how
should the loader treat that default export, a easy solution for this
case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and named
exports like the example at http://jsmodules.io/ which can be sumerized
as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way to
access
the named exports.
As mentioned in the GitHub issue I don't see why you couldn't compile to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
So in that case it would make more sense to treat default as just
another
export name. But if we do that then that means that if we go back to
our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another
commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean that
you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs modules would be
compatible if mixing named and default exports was prohibited, but
the
ability to have both is hard to represent in cjs modules.
Don't understand this, do you have some code examples? I can't see why
that would be the case.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma off...@gmail.com
wrote:
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module`
form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down
to
if a
CJS
module imports an ES6 module that has a key named default, what
should
the
default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma
off...@gmail.com
wrote:
It's using traceur and building the modules to CJS, the project
uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into
a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
Re: Re: Quantifying Default Exports
Interoperability should not be a decisive factor here, we have fallen into
that trap before, the conclusion was to let Loader to handle those cases
rather than trying to drive it from the perspective of the module syntax.
Let's focus on what is best and what makes sense for the ES Modules, and
keep the dynamic module systems out of the picture since we know we have a
lot of flexibility with the loader to deal with those dynamic modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma off...@gmail.com wrote:
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method named
helper or, more likely, the named export is something like call or bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module, importing
the
first one is easy, but when importing the second one slightly less so,
how
should the loader treat that default export, a easy solution for this
case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and
named
exports like the example at http://jsmodules.io/ which can be
sumerized
as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way to
access
the named exports.
As mentioned in the GitHub issue I don't see why you couldn't compile to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
So in that case it would make more sense to treat default as just
another
export name. But if we do that then that means that if we go back to
our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another
commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean that
you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs modules would
be
compatible if mixing named and default exports was prohibited, but
the
ability to have both is hard to represent in cjs modules.
Don't understand this, do you have some code examples? I can't see
why
that would be the case.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma off...@gmail.com
wrote:
Which shows the how the backward compatability argument for
default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module`
form
if you want named imports use the named form.
Default import/exports are generating nothing more then
complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils
down
to
if a
CJS
module imports an ES6 module that has a key named default, what
should
the
default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma
off...@gmail.com
wrote:
It's using traceur and building the modules to CJS, the project
uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports
into
a
check for the named export `default` and use
Re: Re: Quantifying Default Exports
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means give me the Module object with getters to the exports.
But unfortunately in Traceur this is compiling into:
var minimist = require('minimist');
As a result the `module` syntax can possibly return him a 'function' or
other non-Module object. Thus we have broken the ability to parse his code
in the ES6 dynamic loader, as it is not capable of returning a non-Module
object for a module import, which is pretty critical.
Thus default export properties are critical to enabling this support path.
On 21 July 2014 09:51, Caridy Patino car...@gmail.com wrote:
Interoperability should not be a decisive factor here, we have fallen into
that trap before, the conclusion was to let Loader to handle those cases
rather than trying to drive it from the perspective of the module syntax.
Let's focus on what is best and what makes sense for the ES Modules, and
keep the dynamic module systems out of the picture since we know we have a
lot of flexibility with the loader to deal with those dynamic modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma off...@gmail.com wrote:
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method named
helper or, more likely, the named export is something like call or bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module,
importing
the
first one is easy, but when importing the second one slightly less
so,
how
should the loader treat that default export, a easy solution for this
case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and
named
exports like the example at http://jsmodules.io/ which can be
sumerized
as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way to
access
the named exports.
As mentioned in the GitHub issue I don't see why you couldn't compile
to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
So in that case it would make more sense to treat default as just
another
export name. But if we do that then that means that if we go back to
our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another
commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean
that
you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs modules would
be
compatible if mixing named and default exports was prohibited, but
the
ability to have both is hard to represent in cjs modules.
Don't understand this, do you have some code examples? I can't see
why
that would be the case.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma
off...@gmail.com
wrote:
Which shows the how the backward compatability argument for
default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module`
form
if you want named imports use the named form.
Re: Re: Quantifying Default Exports
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com wrote:
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means give me the Module object with getters to the exports.
But unfortunately in Traceur this is compiling into:
var minimist = require('minimist');
As a result the `module` syntax can possibly return him a 'function' or
other non-Module object.
You seem to be saying The traceur implementation of 'module' fails in this
case. It seems to me that Traceur could generate code which would wrap
functions in Module objects. That is, this is not a fundamental limit,
just an unreported bug.
Thus we have broken the ability to parse his code in the ES6 dynamic
loader, as it is not capable of returning a non-Module object for a module
import, which is pretty critical.
Thus default export properties are critical to enabling this support path.
I believe that Caridy's point is: fine, use dynamic linking.
On 21 July 2014 09:51, Caridy Patino car...@gmail.com wrote:
Interoperability should not be a decisive factor here, we have fallen
into that trap before, the conclusion was to let Loader to handle those
cases rather than trying to drive it from the perspective of the module
syntax. Let's focus on what is best and what makes sense for the ES
Modules, and keep the dynamic module systems out of the picture since we
know we have a lot of flexibility with the loader to deal with those
dynamic modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma off...@gmail.com
wrote:
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method named
helper or, more likely, the named export is something like call or
bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module,
importing
the
first one is easy, but when importing the second one slightly less
so,
how
should the loader treat that default export, a easy solution for
this
case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and
named
exports like the example at http://jsmodules.io/ which can be
sumerized
as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way to
access
the named exports.
As mentioned in the GitHub issue I don't see why you couldn't compile
to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
So in that case it would make more sense to treat default as just
another
export name. But if we do that then that means that if we go back
to
our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another
commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean
that
you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs modules
would be
compatible if mixing named and default exports was prohibited,
but
the
ability to have both is hard to represent in cjs modules.
Don't understand this, do you have
Re: The initialization steps for Web browsers
On Tue, 10 Jun 2014, Ian Hickson wrote: On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote: By an ECMAScript Environment (and this is what Ecma-262 defines, although it doesn't actually use that name) I mean a heap of ECMAScript objects (and related values) that may directly reference (point to) each other and a single thread of execution of ECMAScript code. The environment may include multiple global objects. Ok. Sounds like that mays to an event loop, on the HTML side. That should be quite workable. I'll invoke 8.5 when I create an event loop (with zero scripts), and I'll invoke CreateRealm() and then 8.5.1 when I create a Window. So I started trying to figure out how this would work, but I'm still having trouble (sorry). When an event loop is created, we invoke the algorithm in 8.5 Initialization, with step 7 set to obtain zero scripts, right?. Now, the user opens a tab or something, and so a Window object needs to be created. What do I do, exactly? Do I need to create a new realm? New execution context? Both? Do I basically do steps 1-5 of the Initialization steps again? I guess I do nothing else until I see a script; then what do I do? do I create a PendingTask record for the execution of the script, push it to the front of the Task Queue, and let 9.5's NextTask call procede with this new task? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
Yes this is a bug that can be fixed at the compiler level. As you say we
can generate a wrapper when loading a non-ES6 module in ES6:
newModule({
default: require('minimist')
})
We then conditionally add this wrapper based on detecting if the import is
an ES6 module. This is the same method we have for AMD compilations at the
moment, which seems to have been working well.
On 21 July 2014 10:17, John Barton johnjbar...@google.com wrote:
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com
wrote:
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means give me the Module object with getters to the exports.
But unfortunately in Traceur this is compiling into:
var minimist = require('minimist');
As a result the `module` syntax can possibly return him a 'function' or
other non-Module object.
You seem to be saying The traceur implementation of 'module' fails in
this case. It seems to me that Traceur could generate code which would
wrap functions in Module objects. That is, this is not a fundamental
limit, just an unreported bug.
Thus we have broken the ability to parse his code in the ES6 dynamic
loader, as it is not capable of returning a non-Module object for a module
import, which is pretty critical.
Thus default export properties are critical to enabling this support path.
I believe that Caridy's point is: fine, use dynamic linking.
On 21 July 2014 09:51, Caridy Patino car...@gmail.com wrote:
Interoperability should not be a decisive factor here, we have fallen
into that trap before, the conclusion was to let Loader to handle those
cases rather than trying to drive it from the perspective of the module
syntax. Let's focus on what is best and what makes sense for the ES
Modules, and keep the dynamic module systems out of the picture since we
know we have a lot of flexibility with the loader to deal with those
dynamic modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma off...@gmail.com
wrote:
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method named
helper or, more likely, the named export is something like call or
bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module,
importing
the
first one is easy, but when importing the second one slightly less
so,
how
should the loader treat that default export, a easy solution for
this
case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and
named
exports like the example at http://jsmodules.io/ which can be
sumerized
as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way
to
access
the named exports.
As mentioned in the GitHub issue I don't see why you couldn't
compile to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
So in that case it would make more sense to treat default as just
another
export name. But if we do that then that means that if we go back
to
our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another
commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean
that
you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
bugs.ecmascript.org maintenance downtime
bugs.emcascript.org will be down for maintenance starting at 6:00 PM PDT July 21, 2014 ( 22 July 2014, 01:00 UTC). We're getting an updated version of bugzilla and other server updates. Hopefully it will only take a few hours.___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Manipulation of the execution context stack
8.5 Initialization step 4 says Push newContext onto the execution context stack, and step 8 calls NextTask. 8.4.2 NextTask suspends the running execution context in step 2, then in step 3 asserts The execution context stack is now empty. However, I can't find anything in the prose around suspension that actually pops the execution context stack. Am I missing something? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: A way of explicitly reporting exceptions
From: Boris Zbarsky [mailto:bzbar...@mit.edu] On 6/24/14, 9:51 AM, Domenic Denicola wrote: I'd be interested in collaborating on designing such a language extension. I think I would too; I'm just not sure about availability. For posterity, [I tried to replicate this functionality using recursive try-finally][1]. It does not quite work: Chrome reports 1, 2, error, 3 for EventTarget, with 1, 2, 3, error for my custom try-finally version. (Firefox seems to report error, 1, 2, 3 in both cases, which I am guessing is a result of some implementation detail of the console.) So indeed this is not something you can do with JS as it stands. [1]: https://gist.github.com/domenic/722cdac2f9f79f71ad0c ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Manipulation of the execution context stack
On Jul 21, 2014, at 11:23 AM, Ian Hickson wrote: 8.5 Initialization step 4 says Push newContext onto the execution context stack, and step 8 calls NextTask. 8.4.2 NextTask suspends the running execution context in step 2, then in step 3 asserts The execution context stack is now empty. However, I can't find anything in the prose around suspension that actually pops the execution context stack. Am I missing something? A job (task in the version you're looking at) Is always initialized (by NextJob) with an empty execution context stack. NextJob creates a root execution context and then transfers control (a goto, not a call) to the appropriate abstract operation that knows how to start the next job. When that new job eventually completes it will have returned to its initiating abstract operation with an empty execution context stack and its root exeuction context as the active context. Such job initiating abstract operations always end by chaining to another NextJob which suspends (and discards the previous job's root execution context) and starts the process over again for the next job. The execution context stack for a job actually gets emptied by the normal evaluation of the ECMAScript code of the job. However deeply it calls into ES code it always either explicitly returns back up the stack or abnormal completions (typically exceptions) unwinds the stack back to the execution context of the abstract operation that initiated the job). The reason that Initialization in 8.5 initially creates a Realm and an execution context is to put the ES environment into a configuration that matches what NextJob normally expects to find when we use it to transition to the next job. We are essentially faking up an initial current job state that NextJob can switch out of when scheduling the first real job. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Why are Symbol.* all non-configurable and non-writable?
Is this meant to prevent people tampering with them? In that case, global.Symbol should also be non-configurable non-writable or something. Otherwise you can just redefine it. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The initialization steps for Web browsers
On Mon, 21 Jul 2014, Ian Hickson wrote: On Tue, 10 Jun 2014, Ian Hickson wrote: On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote: By an ECMAScript Environment (and this is what Ecma-262 defines, although it doesn't actually use that name) I mean a heap of ECMAScript objects (and related values) that may directly reference (point to) each other and a single thread of execution of ECMAScript code. The environment may include multiple global objects. Ok. Sounds like that mays to an event loop, on the HTML side. That should be quite workable. I'll invoke 8.5 when I create an event loop (with zero scripts), and I'll invoke CreateRealm() and then 8.5.1 when I create a Window. So I started trying to figure out how this would work, but I'm still having trouble (sorry). When an event loop is created, we invoke the algorithm in 8.5 Initialization, with step 7 set to obtain zero scripts, right?. Now, the user opens a tab or something, and so a Window object needs to be created. What do I do, exactly? Do I need to create a new realm? New execution context? Both? Do I basically do steps 1-5 of the Initialization steps again? I guess I do nothing else until I see a script; then what do I do? do I create a PendingTask record for the execution of the script, push it to the front of the Task Queue, and let 9.5's NextTask call procede with this new task? Here's my best guess about how to integrate HTML and ES. So far I've only attempted to describe script execution, but the rest should follow pretty straight-forwardly in theory. When an event loop is created, invoke the algorithm in 8.5 Initialization. Step 7 should obtain zero scripts. This results in 8.4.2 NextTask being invoked. 8.4.2 NextTask is adjusted as follows: The implementation defined unhandled exception processing in step 1 must be the report an error logic in the HTML spec. The implementation defined manner for selecting a non-empty Task Queue in step 4 is to return execution to the calling algorithm; subsequent logic in the HTML spec will then resume the NextTask algorithm when a new task has been primed. When a Window or Worker is created, run 8.5 Initialization steps 1-6, except that in 8.5.1 InitializeFirstRealm, this implementation requires use of an exotic object object to serve as realm’s global object, namely, the Window or WorkerGlobalScope object. Then, suspend the execution context. Stash the realm in the script settings object for the Window. When you load a script, the browser fetches the file, gets the body, decodes it to Unicode, and then creates a PendingTask record whose [[Task]] is ScriptEvaluationTask, whose [[Arguments]] consists of a list with one member, the Unicode characters obtained earlier, and the [[Realm]] is the object stashed in the script settings object. That record is put in the Task Queue, and then the NextTask algorithm is resumed. Does anyone see anything problematic here? Does it look ok? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Manipulation of the execution context stack
On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote: On Jul 21, 2014, at 11:23 AM, Ian Hickson wrote: 8.5 Initialization step 4 says Push newContext onto the execution context stack, and step 8 calls NextTask. 8.4.2 NextTask suspends the running execution context in step 2, then in step 3 asserts The execution context stack is now empty. However, I can't find anything in the prose around suspension that actually pops the execution context stack. Am I missing something? A job (task in the version you're looking at) Is there a more up to date version I can look at? I couldn't quite work out what the canonical file to look at was. I've been using this: http://people.mozilla.org/~jorendorff/es6-draft.html is always initialized (by NextJob) with an empty execution context stack. What step in NextJob does this? It seems that step 3 asserts it, but step 1 doesn't seem to affect the stack, and step 2 refers to the suspend prose, which seems mostly non-normative (I can't quite tell it's normative status -- there's no step-by-step algorithms, which seems to be the way the ES spec indications normativity, but there's no RFC2119-style prose either, so I can't tell the descriptive statements in that section from the prescriptive ones). NextJob creates a root execution context and then transfers control (a goto, not a call) As phrased it's more like a tail-call, but the three are black-box indistinguishable at the spec level, so that's somewhat academic. [...] We are essentially faking up an initial current job state that NextJob can switch out of when scheduling the first real job. I guess what I'm saying is that it's not clear to me where the switch out step happens. Do you have a pointer? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The initialization steps for Web browsers
On Jul 21, 2014, at 10:49 AM, Ian Hickson wrote: On Tue, 10 Jun 2014, Ian Hickson wrote: On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote: By an ECMAScript Environment (and this is what Ecma-262 defines, although it doesn't actually use that name) I mean a heap of ECMAScript objects (and related values) that may directly reference (point to) each other and a single thread of execution of ECMAScript code. The environment may include multiple global objects. Ok. Sounds like that mays to an event loop, on the HTML side. That should be quite workable. I'll invoke 8.5 when I create an event loop (with zero scripts), and I'll invoke CreateRealm() and then 8.5.1 when I create a Window. So I started trying to figure out how this would work, but I'm still having trouble (sorry). When an event loop is created, we invoke the algorithm in 8.5 Initialization, with step 7 set to obtain zero scripts, right?. Now, the user opens a tab or something, and so a Window object needs to be created. What do I do, exactly? Do I need to create a new realm? New execution context? Both? Do I basically do steps 1-5 of the Initialization steps again? I guess I do nothing else until I see a script; then what do I do? do I create a PendingTask record for the execution of the script, push it to the front of the Task Queue, and let 9.5's NextTask call procede with this new task? The abstract operation InitializeFirstRealm is really about setting up the initial environment that will run for actualuser script code. In other words it is what you would want to set up when the first tab or whatever is opened. So if there is no ES code to execution prior to that first user action then you might defer the whole 8.5 initialization process until then. However, if there is some other way to acquire and execute ES code prior to such a user action (for example, FF chrome code, a startup script, etc.) when you would have to do 8.5 initialization earlier. You might use the first Realm for that code or you might use the first Realm as sort of system utility realm, if you have a use for such a thing. The ES spec. currently only has two places a a complete new Realm is created and initialized with a new global object, etc. The places are 8.5.1 InitializeFirstRealm and 26.2.1.1 the Reflect.Realm constructor. However, 26.2.1.1 would normally be invoked from ES code. 8.5.1 is perhaps misnamed as it provides the default steps that a host would use to initialize any host created realm. In other words, for each window/tab you probably want to follow the steps of 8.5.1 to initialize the associated realm. It sounds like I need to give InitializeFirstRealm a better name, such as InitializeHostDefinedRealm. You're right that for each new host created realm you want to repeat steps 1-5 of 8.5. You don't need to have an empty execution context stack to do that initialization although that might actually be the case if the engine is idling waiting for some user initialized action. You're also correct about handling scripts. For each script that is ready to be processed (the source code has been retrieved) you just enqueue a PendingJob record for a ScriptEvaluationJob (15.1.9) with the realm for the job set to the realm that the script runs within. Again, walking through this I can see that I should probably do a little refactoring to make these steps clearer. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
It doesn't seem an issue that requires the ES6 module spec to have
something like default imports though.
The compiler could output
`
newModule({
default: require('minimist')
})
`
and importers could do
`import {default as minimist} from 'minimist';`
Or you could have
`
newModule({
minimist: require('minimist');
})
`
and
`import {minimist} from 'minimist';`
depending on how the compiler is configured/written.
This is implementation detail of compilers and loaders of legacy
systems as opposed to spec concerns.
On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford guybedf...@gmail.com wrote:
Yes this is a bug that can be fixed at the compiler level. As you say we can
generate a wrapper when loading a non-ES6 module in ES6:
newModule({
default: require('minimist')
})
We then conditionally add this wrapper based on detecting if the import is
an ES6 module. This is the same method we have for AMD compilations at the
moment, which seems to have been working well.
On 21 July 2014 10:17, John Barton johnjbar...@google.com wrote:
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com
wrote:
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means give me the Module object with getters to the
exports.
But unfortunately in Traceur this is compiling into:
var minimist = require('minimist');
As a result the `module` syntax can possibly return him a 'function' or
other non-Module object.
You seem to be saying The traceur implementation of 'module' fails in
this case. It seems to me that Traceur could generate code which would
wrap functions in Module objects. That is, this is not a fundamental limit,
just an unreported bug.
Thus we have broken the ability to parse his code in the ES6 dynamic
loader, as it is not capable of returning a non-Module object for a module
import, which is pretty critical.
Thus default export properties are critical to enabling this support
path.
I believe that Caridy's point is: fine, use dynamic linking.
On 21 July 2014 09:51, Caridy Patino car...@gmail.com wrote:
Interoperability should not be a decisive factor here, we have fallen
into that trap before, the conclusion was to let Loader to handle those
cases rather than trying to drive it from the perspective of the module
syntax. Let's focus on what is best and what makes sense for the ES
Modules,
and keep the dynamic module systems out of the picture since we know we
have
a lot of flexibility with the loader to deal with those dynamic modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma off...@gmail.com
wrote:
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method
named
helper or, more likely, the named export is something like call or
bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module,
importing
the
first one is easy, but when importing the second one slightly less
so,
how
should the loader treat that default export, a easy solution for
this
case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and
named
exports like the example at http://jsmodules.io/ which can be
sumerized
as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way
to
access
the named exports.
As mentioned in the GitHub issue I don't see why you couldn't
compile to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
So in that case it would make more sense to treat default as just
another
export name. But if we do that then that means that if we go back
to
our
second example
```js
//cj2es6.js
export default function () {}
Re: Manipulation of the execution context stack
On Jul 21, 2014, at 1:29 PM, Ian Hickson wrote: On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote: On Jul 21, 2014, at 11:23 AM, Ian Hickson wrote: 8.5 Initialization step 4 says Push newContext onto the execution context stack, and step 8 calls NextTask. 8.4.2 NextTask suspends the running execution context in step 2, then in step 3 asserts The execution context stack is now empty. However, I can't find anything in the prose around suspension that actually pops the execution context stack. Am I missing something? A job (task in the version you're looking at) Is there a more up to date version I can look at? I couldn't quite work out what the canonical file to look at was. I've been using this: I just release a new PDF draft Friday at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#july_18_2014_draft_rev_26 http://people.mozilla.org/~jorendorff/es6-draft.html Hopefully, Jason will soon have the HTML version ready is always initialized (by NextJob) with an empty execution context stack. What step in NextJob does this? It seems that step 3 asserts it, but step 1 doesn't seem to affect the stack, and step 2 refers to the suspend prose, which seems mostly non-normative (I can't quite tell it's normative status -- there's no step-by-step algorithms, which seems to be the way the ES spec indications normativity, but there's no RFC2119-style prose either, so I can't tell the descriptive statements in that section from the prescriptive ones). It's because NextJob is only supposed to be used within an Job initiation abstract operation that is passed to EnqueueJob. So, since we start with an empty stack in 8.5 and each job each returns/unwinds to its starting context it flows like this empty stack create dummy root context 8.5 Initialization, does stuff returns/unwinds to dummy root context NextJob, deletes dummy root context, creates root context for first job runs the initialization abstract operation for first job returns/unwinds to first job root context NextJob deletes first job root context, creates root context for second job etc... NextJob creates a root execution context and then transfers control (a goto, not a call) As phrased it's more like a tail-call, but the three are black-box indistinguishable at the spec level, so that's somewhat academic. [...] We are essentially faking up an initial current job state that NextJob can switch out of when scheduling the first real job. I guess what I'm saying is that it's not clear to me where the switch out step happens. Do you have a pointer? Did this help. It essential to the process that jobs always unwind back to its root context. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are Symbol.* all non-configurable and non-writable?
Because somebody thought it was a good idea ;-) ... On Jul 21, 2014, at 1:04 PM, Boris Zbarsky wrote: Is this meant to prevent people tampering with them? In that case, global.Symbol should also be non-configurable non-writable or something. Otherwise you can just redefine it. You're probably right that locking down one doesn't make all that much sense without locking down the other. We have a history of not make global object properties readonly/non-configurable. There also may be configurability issues for dynamically created Realms that we'd want to think about before making Symbol readonly/non-writable. Probably with some more discussion. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are Symbol.* all non-configurable and non-writable?
Because somebody thought it was a good idea ;-) ... I'd say for consistency with other constant value properties (NaN, Infinity, undefined, Math.*, Number.*). On Jul 21, 2014, at 1:04 PM, Boris Zbarsky wrote: / Is this meant to prevent people tampering with them? // // In that case, global.Symbol should also be non-configurable non-writable or something. Otherwise you can just redefine it. / You're probably right that locking down one doesn't make all that much sense without locking down the other. We have a history of not make global object properties readonly/non-configurable. There also may be configurability issues for dynamically created Realms that we'd want to think about before making Symbol readonly/non-writable. Probably with some more discussion. Allen - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Manipulation of the execution context stack
On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote: Is there a more up to date version I can look at? I couldn't quite work out what the canonical file to look at was. I've been using this: I just release a new PDF draft Friday at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#july_18_2014_draft_rev_26 Ah, cool, thanks. (Is there a URL that will always point to the very latest version, by any chance?) is always initialized (by NextJob) with an empty execution context stack. What step in NextJob does this? It seems that step 3 asserts it, but step 1 doesn't seem to affect the stack, and step 2 refers to the suspend prose, which seems mostly non-normative (I can't quite tell it's normative status -- there's no step-by-step algorithms, which seems to be the way the ES spec indications normativity, but there's no RFC2119-style prose either, so I can't tell the descriptive statements in that section from the prescriptive ones). It's because NextJob is only supposed to be used within an Job initiation abstract operation that is passed to EnqueueJob. So, since we start with an empty stack in 8.5 and each job each returns/unwinds to its starting context it flows like this empty stack create dummy root context 8.5 Initialization, does stuff The does stuff in particular includes step 5, Push newContext onto the execution context stack. returns/unwinds to dummy root context Where? NextJob, deletes dummy root context Where? Step 3 of NextJob says Assert: The execution context stack is now empty, but I don't see anything that undoes the effect of 8.5's step 5, which makes it not empty. I admit I haven't made an exhaustive search of all the algorithms directly and indirectly called by 8.5. I started trying to trace all the steps between 8.5:5 and NextJob:3 in this e-mail, but that's a lot of calls so it's probably not worth including here. Do you have a precise pointer to the actual step that unwinds the stack? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
There are two issues here:
1) Is 'default' essential?
2) Should the spec. explicitly define commonjs loading?
Brian is claiming 1) no and 2) no. More important for me: does 2) require
1). Evidently not.
jjb
On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma off...@gmail.com wrote:
It doesn't seem an issue that requires the ES6 module spec to have
something like default imports though.
The compiler could output
`
newModule({
default: require('minimist')
})
`
and importers could do
`import {default as minimist} from 'minimist';`
Or you could have
`
newModule({
minimist: require('minimist');
})
`
and
`import {minimist} from 'minimist';`
depending on how the compiler is configured/written.
This is implementation detail of compilers and loaders of legacy
systems as opposed to spec concerns.
On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford guybedf...@gmail.com wrote:
Yes this is a bug that can be fixed at the compiler level. As you say we
can
generate a wrapper when loading a non-ES6 module in ES6:
newModule({
default: require('minimist')
})
We then conditionally add this wrapper based on detecting if the import
is
an ES6 module. This is the same method we have for AMD compilations at
the
moment, which seems to have been working well.
On 21 July 2014 10:17, John Barton johnjbar...@google.com wrote:
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com
wrote:
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means give me the Module object with getters to the
exports.
But unfortunately in Traceur this is compiling into:
var minimist = require('minimist');
As a result the `module` syntax can possibly return him a 'function' or
other non-Module object.
You seem to be saying The traceur implementation of 'module' fails in
this case. It seems to me that Traceur could generate code which would
wrap functions in Module objects. That is, this is not a fundamental
limit,
just an unreported bug.
Thus we have broken the ability to parse his code in the ES6 dynamic
loader, as it is not capable of returning a non-Module object for a
module
import, which is pretty critical.
Thus default export properties are critical to enabling this support
path.
I believe that Caridy's point is: fine, use dynamic linking.
On 21 July 2014 09:51, Caridy Patino car...@gmail.com wrote:
Interoperability should not be a decisive factor here, we have fallen
into that trap before, the conclusion was to let Loader to handle
those
cases rather than trying to drive it from the perspective of the
module
syntax. Let's focus on what is best and what makes sense for the ES
Modules,
and keep the dynamic module systems out of the picture since we know
we have
a lot of flexibility with the loader to deal with those dynamic
modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma off...@gmail.com
wrote:
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method
named
helper or, more likely, the named export is something like call or
bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do
so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module,
importing
the
first one is easy, but when importing the second one slightly
less
so,
how
should the loader treat that default export, a easy solution for
this
case
is to simply have default exports act the same as a
module.exports
But then what would you do about es6 modules that use default
and
named
exports like the example at http://jsmodules.io/ which can be
sumerized
as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no
way
to
access
the named exports.
Re: Manipulation of the execution context stack
On Jul 21, 2014, at 2:35 PM, Ian Hickson wrote: On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote: (Is there a URL that will always point to the very latest version, by any chance?) http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts is always initialized (by NextJob) with an empty execution context stack. What step in NextJob does this? It seems that step 3 asserts it, but step 1 doesn't seem to affect the stack, and step 2 refers to the suspend prose, which seems mostly non-normative (I can't quite tell it's normative status -- there's no step-by-step algorithms, which seems to be the way the ES spec indications normativity, but there's no RFC2119-style prose either, so I can't tell the descriptive statements in that section from the prescriptive ones). It's because NextJob is only supposed to be used within an Job initiation abstract operation that is passed to EnqueueJob. So, since we start with an empty stack in 8.5 and each job each returns/unwinds to its starting context it flows like this empty stack create dummy root context 8.5 Initialization, does stuff The does stuff in particular includes step 5, Push newContext onto the execution context stack. yes returns/unwinds to dummy root context Where? This is largely implicit in the ES spec. algorithm conventions (5.2). Abstract operations call each other in a strict call/return manner. Exceptional control flows (such an ES level throw or return statements) are modeled using completion records (6.2.2) that are returned as values from the abstract operations. The execution context stack (8.3) is used to track ES level function activations/returns but not specification level call/returns from abstract operations. Execution contexts are explicitly pushed on to the context stack by call-related abstract operations and explicitly removed at function boundaries for ES return statements and when propagating throw completion records past a ES function call boundary. steps 2-5 of 8.5 establishes the dummy root context, it's the active context when InitializeFirstRealm is performed in step 6. If any thing performed by InitializeFirstRealm happens to create/push additional execution contexts they will be popped by the time we return to step 7 of 8.5. Step 9 is a NextJob macro and step 2 of NextJob suspends the running execution context which in this case is the dummy root context created in steps 2-5. (I just added and remove it from the execution context stack to the text NewJob step 2 to make it explicit that suspending the running execution context also removes it from the stack. Steps 6-8 then creates a new root execution context for the next job... NextJob, deletes dummy root context Where? step 2. Step 3 of NextJob says Assert: The execution context stack is now empty, but I don't see anything that undoes the effect of 8.5's step 5, which makes it not empty. I admit I haven't made an exhaustive search of all the algorithms directly and indirectly called by 8.5. I started trying to trace all the steps between 8.5:5 and NextJob:3 in this e-mail, but that's a lot of calls so it's probably not worth including here. Does the text I added to step 2 clear this up? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
Wasn't the original issue single exports and their demonstrated utility in
node and AMD?
On Jul 21, 2014 5:49 PM, John Barton johnjbar...@google.com wrote:
There are two issues here:
1) Is 'default' essential?
2) Should the spec. explicitly define commonjs loading?
Brian is claiming 1) no and 2) no. More important for me: does 2) require
1). Evidently not.
jjb
On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma off...@gmail.com wrote:
It doesn't seem an issue that requires the ES6 module spec to have
something like default imports though.
The compiler could output
`
newModule({
default: require('minimist')
})
`
and importers could do
`import {default as minimist} from 'minimist';`
Or you could have
`
newModule({
minimist: require('minimist');
})
`
and
`import {minimist} from 'minimist';`
depending on how the compiler is configured/written.
This is implementation detail of compilers and loaders of legacy
systems as opposed to spec concerns.
On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford guybedf...@gmail.com
wrote:
Yes this is a bug that can be fixed at the compiler level. As you say
we can
generate a wrapper when loading a non-ES6 module in ES6:
newModule({
default: require('minimist')
})
We then conditionally add this wrapper based on detecting if the import
is
an ES6 module. This is the same method we have for AMD compilations at
the
moment, which seems to have been working well.
On 21 July 2014 10:17, John Barton johnjbar...@google.com wrote:
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com
wrote:
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means give me the Module object with getters to the
exports.
But unfortunately in Traceur this is compiling into:
var minimist = require('minimist');
As a result the `module` syntax can possibly return him a 'function'
or
other non-Module object.
You seem to be saying The traceur implementation of 'module' fails in
this case. It seems to me that Traceur could generate code which
would
wrap functions in Module objects. That is, this is not a fundamental
limit,
just an unreported bug.
Thus we have broken the ability to parse his code in the ES6 dynamic
loader, as it is not capable of returning a non-Module object for a
module
import, which is pretty critical.
Thus default export properties are critical to enabling this support
path.
I believe that Caridy's point is: fine, use dynamic linking.
On 21 July 2014 09:51, Caridy Patino car...@gmail.com wrote:
Interoperability should not be a decisive factor here, we have fallen
into that trap before, the conclusion was to let Loader to handle
those
cases rather than trying to drive it from the perspective of the
module
syntax. Let's focus on what is best and what makes sense for the ES
Modules,
and keep the dynamic module systems out of the picture since we know
we have
a lot of flexibility with the loader to deal with those dynamic
modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma off...@gmail.com
wrote:
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method
named
helper or, more likely, the named export is something like call or
bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma
off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do
so
currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module,
importing
the
first one is easy, but when importing the second one slightly
less
so,
how
should the loader treat that default export, a easy solution
for
this
case
is to simply have default exports act the same as a
module.exports
But then what would you do about es6 modules that use default
and
named
exports like the example at http://jsmodules.io/ which can be
sumerized
as
```js
export default
Re: Re: Quantifying Default Exports
What utility is that exactly? They are easier to import in terms of typing?
I would hope that with ES6 modules all a programmer would have to
write is the name of the import and the IDE would auto insert the
import statement.
The sort of IDE support you would see for Java or C#, of course that
will only work with named exports.
If everything is default then the IDE can't help that much when it
comes to auto complete and inserts.
I think that issue has already been addressed by people pointing out
that modules were written in the default style due to named exports
being ugly in CJS.
On Mon, Jul 21, 2014 at 11:30 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
Wasn't the original issue single exports and their demonstrated utility in
node and AMD?
On Jul 21, 2014 5:49 PM, John Barton johnjbar...@google.com wrote:
There are two issues here:
1) Is 'default' essential?
2) Should the spec. explicitly define commonjs loading?
Brian is claiming 1) no and 2) no. More important for me: does 2) require
1). Evidently not.
jjb
On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma off...@gmail.com wrote:
It doesn't seem an issue that requires the ES6 module spec to have
something like default imports though.
The compiler could output
`
newModule({
default: require('minimist')
})
`
and importers could do
`import {default as minimist} from 'minimist';`
Or you could have
`
newModule({
minimist: require('minimist');
})
`
and
`import {minimist} from 'minimist';`
depending on how the compiler is configured/written.
This is implementation detail of compilers and loaders of legacy
systems as opposed to spec concerns.
On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford guybedf...@gmail.com
wrote:
Yes this is a bug that can be fixed at the compiler level. As you say
we can
generate a wrapper when loading a non-ES6 module in ES6:
newModule({
default: require('minimist')
})
We then conditionally add this wrapper based on detecting if the import
is
an ES6 module. This is the same method we have for AMD compilations at
the
moment, which seems to have been working well.
On 21 July 2014 10:17, John Barton johnjbar...@google.com wrote:
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com
wrote:
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in
ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means give me the Module object with getters to the
exports.
But unfortunately in Traceur this is compiling into:
var minimist = require('minimist');
As a result the `module` syntax can possibly return him a 'function'
or
other non-Module object.
You seem to be saying The traceur implementation of 'module' fails in
this case. It seems to me that Traceur could generate code which
would
wrap functions in Module objects. That is, this is not a fundamental
limit,
just an unreported bug.
Thus we have broken the ability to parse his code in the ES6 dynamic
loader, as it is not capable of returning a non-Module object for a
module
import, which is pretty critical.
Thus default export properties are critical to enabling this support
path.
I believe that Caridy's point is: fine, use dynamic linking.
On 21 July 2014 09:51, Caridy Patino car...@gmail.com wrote:
Interoperability should not be a decisive factor here, we have
fallen
into that trap before, the conclusion was to let Loader to handle
those
cases rather than trying to drive it from the perspective of the
module
syntax. Let's focus on what is best and what makes sense for the ES
Modules,
and keep the dynamic module systems out of the picture since we know
we have
a lot of flexibility with the loader to deal with those dynamic
modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma off...@gmail.com
wrote:
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature
doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method
named
helper or, more likely, the named export is something like call
or
bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma
off...@gmail.com
wrote:
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6
Re: The initialization steps for Web browsers
On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote: Yes, this is pretty much what I had in mind. Cool, thanks. I mentioned in other message, I can refractor things a bit to make it a bit easier to express. Cool, ok. Let me know when I should start speccing things on my end. However, Realms don't provide the isolation that is required for different origin documents. See the discussion at https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/7 I think this is confusing two things: the same-origin policy, and event loops. Multiple documents with different effective script origins can (and frequently do) share one event loop, with script from one origin on the stack below script from another origin. In single-process browsers, there's only one event loop, even though they support cross-origin iframes, tabs, etc. In fact, to make it worse, scripts can on-the-fly change their origin using document.domain. Exactly how this works isn't exactly defined yet, but the work to define this is described here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 It's defined at a level slightly above ES itself. It doesn't re-use the realm machinery per se. What prevents two realms from different origins from ever sharing anything isn't anything in ES, it's just that we never actually provide a way for references to make it across (except in edge cases involving document.domain manipulation, though those only allow it for what we call similar origins). Event loops, though, are true isolation. If a browser has two documents in two different event loops, they can never share anything. They have different heaps, stacks, etc. Structured cloning was invented to allow data to be passed between event loops. However, even with one event loop, you still need structured cloning to tranfser data between realms sometimes, because the Web platform logically isolates them, as discussed above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' [ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are Symbol.* all non-configurable and non-writable?
On 7/21/14, 5:19 PM, André Bargull wrote: I'd say for consistency with other constant value properties (NaN, Infinity, undefined, Math.*, Number.*). Ah, interesting. I hadn't realized that Math.* and Number.* were also readonly non-configurable. Alright, that's as good a reason as any. ;) -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
