On Dec 4, 2012, at 8:54 AM, Kevin Smith <khs4...@gmail.com> wrote:

> Particularly worrisome to me is the suggestion that the default loading 
> behavior should map:
> 
>     import x from "foo";
> 
> to:
> 
>     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.

Dave

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to