Hi James,
> 1) Files as modules do not need module wrapper
> ====================
> Just to confirm, if a JS file contains only a module definition, the
> module X{} wrapper is not needed?
That's correct.
>
> 2) Set module export value
> ====================
>
> Is it possible to support setting the value of the module to be a
> function or some other value?
Currently, there's nothing like this in the proposal, but I remember you
blogged about this before. Harmony modules are static entities, and setting
their "value" dynamically would clash with the design goals of static importing
and exporting.
That said, we could consider adding functionality to make a module callable, to
address the use case you describe. Thanks for bringing this up.
> 3) Are "module" and "import" needed inside a module?
> ====================
There are two questions here:
3a) Is "module" needed inside a module?
Yes. A module declaration declares a binding to a static module. A let/var
declaration declares a binding to a dynamic value. You only get compile-time
linking and scoping with static modules.
3b) Is "import" needed inside a module?
I think the answer here is technically no. You're right that you could
generally use let/var and destructuring, except for the import M.* case. If we
allowed you to destructure a runtime expression and dynamically bind all its
variables, we would be re-introducing `with' into Harmony, which we will never,
ever, ever do. :)
The other difference -- at least in the current state of the proposal -- is
that you can't use a `require' form in an ordinary expression, only in the RHS
of an import/module declaration. This doesn't show up in the Geometry example
you cited, but if you wanted to import from an external module using `let', you
would have to use the callback API:
ModuleLoader.load("geometry.js", function(Geometry) {
let { draw } = Geometry;
...
});
(We've talked a little bit about generalizing the `require' form to be an
expression operator that does a static module load, but I'm not sure whether it
hangs together.)
> The end goal is trying limit the number of new special things in the
> language the developer needs to learn for modules. Ideally it would
> be: "use 'module' to declare an inline module, then use require('')
> inside it to get handles on other modules, and use var/let and
> destructuring as you normally would".
For many cases, I think that's fine. But .* is an important convenience for
scripting. Also, FWIW, import is already reserved and has symmetry with export,
so it seems like a wasted opportunity to fill a natural space in the grammar.
> 4) How to optimize
> ====================
I think this is beyond the scope of ECMAScript.next. People are still figuring
out how to optimize delivery, and web performance patterns are still shaking
out. ISTM there will be situations where it's more performant to combine many
modules into one (which can be done with nested module declarations) and others
where it's more performant to conditionally/lazily load modules separately
(which can be done with module loaders). I don't currently have a clear picture
of how we could build syntactic conveniences or abstractions for doing this,
but at least the pieces are there so programmers have the building blocks to
start constructing their own tools for doing this.
> 5) Loader plugins
> ====================
>
> Some of the AMD loaders support loader plugins[7].
Missing a reference in your bibliography. :)
> This allows an AMD
> module to load other types of resources, and a module can treat them
> as a dependency.
I don't know-- I'd be interested to read more on this topic.
> 6) Loader API: multiple modules
> ====================
>
> The loader API seems to only allow loading one module at a time with a
> callback (looking at Loader.load). Is there a way to say "load these
> three modules, and call this callback when all three are loaded"?
Perhaps. We're trying to get the building blocks in place first. We can figure
out what conveniences are needed on top of that.
BTW, what you're asking for is essentially a concurrent join, which is
convenient to express in a new library I'm working on called jsTask:
let [m1, m2, m3] = yield join(load("m1.js"), load("m2.js"), load("m3.js"));
> 7) Cross-domain script loading
> ====================
>
> Given the modules examples page, it looks like it will be possible to
> load scripts from other domains, just confirming that it will be
> allowed, particularly in the browser.
Yep!
Thanks for the questions,
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
