Comments on Meeting Notes
dherman at mozilla.com
Tue Dec 4 11:31:38 PST 2012
On Dec 4, 2012, at 8:54 AM, Kevin Smith <khs4473 at gmail.com> wrote:
> Particularly worrisome to me is the suggestion that the default loading behavior should map:
> import x from "foo";
> System.baseURL + "foo" + ".js"
> This is contrary to all url resolution algorithms on the web, and involves way too much magic.
As James says, it's not contrary to AMD, and it's also similar to NPM. And it's similar to systems like YUI, but in a slightly different way: instead of the nesting structure of modules being expressed as nested objects, it's expressed as nested logical names.
This came about as a result of a couple things: First, James raised a concern that there's a kind of impedance mismatch between the string/filesystem nesting and the dotted sub-module nesting, and it wasn't clear how to decide between them, or how the naming of a filesystem structure should map to the naming of dot-paths as the result of a build tool.
But second, we realized that the whole initial design of binding module names to identifiers (as opposed to string names) no longer solved the problem it was initially supposed to solve. An application needs to set up a configuration or registry where components can get at other components by some sort of naming convention. Originally this was achieved by binding modules to variables that were globally accessible and implicitly shared in scope with other modules. This was problematic for various reasons and removed, but now it was no longer possible to use variables to create a shared registry of the modules in the system. And yet, at the same time, the loader *did* contain such a registry.
Finally, this makes for a more straightforward equivalence between modules in separate files and modules concatenated together into a single file; they can be given names that match the names that would match the logical names that map to the filesystem, so the code that uses them doesn't have to change.
> In general, I would like to see more updates and more convergence regarding the modules specification, as many of us are now aiming at a (seemingly) wildly moving target.
Well, the standard isn't out yet, so to some degree this is part of the process. But I take the blame for this stuff not happening sooner. I am actively working on modules, and trying to nail this all down as soon as possible.
More information about the es-discuss