exports at the top of the file

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

exports at the top of the file

Raul-Sebastian Mihăilă
Douglas Crockford said that eventually JSLint would require exports at the top of the file. However I think there are some issues.

If my understanding is correct,

```js
export default myConst;
const myConst = {};
```

would throw because when the export is evaluated, in step 2 of the Evaluation algorithm applied to the ExportDeclaration: export default AssignmentExpression; production (https://tc39.github.io/ecma262/#sec-exports-runtime-semantics-evaluation), the value of the assignment expression is retrieved, which should cause an error because the binding has not yet been initialized.

I'm not sure what should happen if myConst was exported with an ExportClause.

```js
export {myConst};
const myConst = {};
```

In this case, the Evaluation algorithm just returns a normal completion. But I think that it depends on when myConst is indirectly accessed in the importing modules. If it's accessed before `const myConst` is evaluated, then I believe it would be uninitialized and would throw. Otherwise, it would work.

Is my understanding correct? Thanks!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: exports at the top of the file

Logan Smyth
```js
export default myConst;
const myConst = {};
```
would throw because when the export is evaluated

Correct, if you wanted to export `myConst` as the default without that issue, you'd want to do

```
export {myConst as default};
const myConst = {};
```
to declaratively expose the binding under the default name, without requiring the value be available at the time.

The key thing to remember with exports is that they are all processed before the JS has even begin executing, and as you saw, are no-ops at execution time, aside from `export default myConst` which is essentially sugar for

```
const _hiddenBinding = myConst;
export {_hiddenBinding as default};
```

where the fact that a default binding exists is known at parse time. Only the value of the export is assigned at evaluation time.

```js
export {myConst};
const myConst = {};
```

This is not an issue. Export declarations define mappings of module-local binding names, to publicly exposed export names, and that is all, they do not access the value in any way on their own. It's possible that if you had some circular dependencies in your code, something could access `myConst` before it had been initialized, and that would result in a TDZ error the same way any other attempt to access the value would.


On Mon, Jun 6, 2016 at 9:39 PM, Raul-Sebastian Mihăilă <[hidden email]> wrote:
Douglas Crockford said that eventually JSLint would require exports at the top of the file. However I think there are some issues.

If my understanding is correct,

```js
export default myConst;
const myConst = {};
```

would throw because when the export is evaluated, in step 2 of the Evaluation algorithm applied to the ExportDeclaration: export default AssignmentExpression; production (https://tc39.github.io/ecma262/#sec-exports-runtime-semantics-evaluation), the value of the assignment expression is retrieved, which should cause an error because the binding has not yet been initialized.

I'm not sure what should happen if myConst was exported with an ExportClause.

```js
export {myConst};
const myConst = {};
```

In this case, the Evaluation algorithm just returns a normal completion. But I think that it depends on when myConst is indirectly accessed in the importing modules. If it's accessed before `const myConst` is evaluated, then I believe it would be uninitialized and would throw. Otherwise, it would work.

Is my understanding correct? Thanks!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: exports at the top of the file

Ben Newman
Is it possible that Crock meant export declarations should be restricted to the *top level* of the file? In other words, they can't be nested in conditional blocks or inside functions, but they can appear anywhere in the outermost scope of the module?

If so, that's effectively what ECMAScript 2015 already requires: http://www.ecma-international.org/ecma-262/6.0/index.html#sec-modules (note that StatementListItem can never produce additionalExportDeclaration symbols).

All export declarations define some number of exported symbol names (even export defaultdeclarations, where the name is "default"). Some export declarations also declare local variables, functions, or classes, or evaluate default expressions. It's important to keep in mind that the definition of exported symbols is conceptually hoisted to the beginning of the module, while the initialization of local entities happens wherever it normally would (function declarations are also hoisted, but variables and classes are not, and of course default expressions must be evaluated in their original position, for the reasons mentioned by Logan S.).

In other words, for export declarations that only define exported symbols (e.g. export { a, b as c }), it doesn't really matter where they appear in the file, because (thanks to hoisting) it's as if you wrote them at the beginning of the file, anyway.

That's my understanding, at least :)

Ben

On Tue, Jun 7, 2016 at 12:58 AM Logan Smyth <[hidden email]> wrote:
```js
export default myConst;
const myConst = {};
```
would throw because when the export is evaluated

Correct, if you wanted to export `myConst` as the default without that issue, you'd want to do

```
export {myConst as default};
const myConst = {};
```
to declaratively expose the binding under the default name, without requiring the value be available at the time.

The key thing to remember with exports is that they are all processed before the JS has even begin executing, and as you saw, are no-ops at execution time, aside from `export default myConst` which is essentially sugar for

```
const _hiddenBinding = myConst;
export {_hiddenBinding as default};
```

where the fact that a default binding exists is known at parse time. Only the value of the export is assigned at evaluation time.

```js
export {myConst};
const myConst = {};
```

This is not an issue. Export declarations define mappings of module-local binding names, to publicly exposed export names, and that is all, they do not access the value in any way on their own. It's possible that if you had some circular dependencies in your code, something could access `myConst` before it had been initialized, and that would result in a TDZ error the same way any other attempt to access the value would.


On Mon, Jun 6, 2016 at 9:39 PM, Raul-Sebastian Mihăilă <[hidden email]> wrote:
Douglas Crockford said that eventually JSLint would require exports at the top of the file. However I think there are some issues.

If my understanding is correct,

```js
export default myConst;
const myConst = {};
```

would throw because when the export is evaluated, in step 2 of the Evaluation algorithm applied to the ExportDeclaration: export default AssignmentExpression; production (https://tc39.github.io/ecma262/#sec-exports-runtime-semantics-evaluation), the value of the assignment expression is retrieved, which should cause an error because the binding has not yet been initialized.

I'm not sure what should happen if myConst was exported with an ExportClause.

```js
export {myConst};
const myConst = {};
```

In this case, the Evaluation algorithm just returns a normal completion. But I think that it depends on when myConst is indirectly accessed in the importing modules. If it's accessed before `const myConst` is evaluated, then I believe it would be uninitialized and would throw. Otherwise, it would work.

Is my understanding correct? Thanks!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: exports at the top of the file

Raul-Sebastian Mihăilă
In reply to this post by Logan Smyth

I don't think it was related to nesting. Anyway, I wrote to him something similar to what I wrote here and later he agreed. Thanks for confirming.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss