Modules Question
We would probably make it a contextual keyword so you could still use it in non-expression contexts (e.g., to the right of '.' and left of ':' in object literals), but unless we played some clever tricks, which I'm not sure would be worth it, using it as an identifier would be a syntax error. Harmony will be opt-in, though, so this won't cause existing code to break unless the author explicitly changes the language; at which point they would get an early error and have the opportunity to rename the identifiers.
On Tue, Dec 28, 2010 at 8:06 AM, David Herman <dherman at mozilla.com> wrote:
We would probably make it a contextual keyword so you could still use it in non-expression contexts (e.g., to the right of '.' and left of ':' in object literals), but unless we played some clever tricks, which I'm not sure would be worth it, using it as an identifier would be a syntax error. Harmony will be opt-in, though, so this won't cause existing code to break unless the author explicitly changes the language; at which point they would get an early error and have the opportunity to rename the identifiers.
Nit: All identifiers including all keywords can already be used after a '.' or before a ':' in object literals.
While I'm at it (and feel free to direct me to the archives if this has already been discussed):
Say I'm developing a library, and I have two files with one module per file, like this:
/project a.js b.js
How would I bring "b" into "a"? Like this?
// a.js module a { module b = "b.js"; }
Or would I use "import" like the file system modulesstrawman:simple_modules_examples#filesystem_modules_for_offline_esexample?
Thanks again.
There's some flexibility built in to the system via module loaders. The "filesystem modules" example is hypothetical; it assumes a built-in module loader that maps files available on the filesystem to corresponding pre-defined, nested modules.
On the web, you would do almost as you suggest:
// a.js module a { module b = "b.js"; }
except that a.js doesn't name itself; it's named by the script that loads it:
// a.js
module b = "b.js";
...
// b.js
...
// project.html
...
<script type="harmony">
module a = "a.js";
</script>
Dave
PS I will be updating the wiki pages soon to reflect some of the finer-grained details and tweaks I've made to the design based on my experience prototyping modules in Narcissus (mozilla/narcissus). I'll ping the list when the pages are updated.
Sweet - I was hoping that the module wouldn't have to name itself.
My next question has to do with bundling. Let's say I want to bundle a.js and b.js into a single file, with the exports of a.js providing the exports of this bundled "thing". I suppose I could wrap both of the individual modules something like this:
module a { /* a.js text / } module b { / b.js text */ }
export a; // ? Not sure about this one
But will the runtime know how to correctly resolve the (module b = "b.js";) that comes from a.js? Or will that declaration have to be rewritten?
I'm not quite sure I understand the scenario you're describing. Do you mean that we dump the contents of a.js and b.js into all.js and delete the first two files? In that case you can do:
// all.js:
export module a {
export module b {
// original b.js contents ...
}
// original a.js contents ...
}
But I'm not sure if I'm getting what you want the example to be.
Ah - that's much more elegant. Let me see if I can describe better though.
I want to keep my library in source form as separate modules (one module per file, probably). I'll do development and testing that way. But I want to distribute my library as a single file. Presumably I'll need some tool to "bundle" all of the component modules together. I'm just trying to get a mental picture of what such a tool would have to do. It seems like we'd need to rewrite the module declarations (i.e. module b = "b.js";) but to what? Or would we?
I see -- interesting use case! Yes, you'd need to transform external module declarations into local module definitions. But it should be pretty straightforward: wherever you see
module m = "foo.js";
you replace it with
module m {
// contents of foo.js (recursively transformed)
}
(Incidentally, I've been working (off and on) on an API that exposes SpiderMonkey's internal parser to JavaScript code, so that a JS program can take a string, parse it as JS source, and get back a JS object representing the AST. This should be helpful for building these kinds of tools.
https://developer.mozilla.org/en/SpiderMonkey/Parser_API
When I can find the time, I also want to write a JS pretty-printer that can take one of these AST's and output JS source again.)
In the modules strawman, "module" is a keyword, right? Will code that uses "module" as an identifier most likely cause a syntax error?