ModuleImport
Bruno Jouhier
bjouhier at gmail.com
Sat Jun 28 08:15:24 PDT 2014
Why make things so complex and introduce so many syntax variations? The
following should be sufficient:
import "underscore" as _; // var _ = require('underscore');
And there should be an API (not a language construct) to import a module
dynamically (and asynchronously). Something like:
promise = importModule(path);
Why introduce an export syntax? Why not just use this (or exports)?
this.foo = ... // or exports.foo = ...
this = .... // or exports = ..., similar to module.exports = ...
// importer obtains value of this / exports at end of module file,
// as if `return this` was added at the end of the file.
This would give the same power / flexibility as CommonJS and a simple
compatibility path. This would eliminate the "default" exports problem
because it would allow a module to export a function. It is also easy to
explain.
There is an operational requirement to have a special syntax for import
because this is what allows loaders to build a dependency graph and
optimize dependency loading. But there is no "operational" requirement to
have a special syntax for export. Static checking on exported members feels
odd.
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140628/286bec86/attachment.html>
More information about the es-discuss
mailing list