Re: 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. Dave On Dec 28, 2010, at 7:34 AM, Kevin Smith wrote: In the modules strawman, module is a keyword, right? Will code that uses module as an identifier most likely cause a syntax error? Thanks! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules Question
On Tue, Dec 28, 2010 at 8:06 AM, David Herman dher...@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. Dave On Dec 28, 2010, at 7:34 AM, Kevin Smith wrote: In the modules strawman, module is a keyword, right? Will code that uses module as an identifier most likely cause a syntax error? Thanks! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules Question
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
moduleshttp://wiki.ecmascript.org/doku.php?id=strawman:simple_modules_examples#filesystem_modules_for_offline_esexample?
Thanks again.
On Tue, Dec 28, 2010 at 12:09 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Dec 28, 2010 at 8:06 AM, David Herman dher...@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.
Dave
On Dec 28, 2010, at 7:34 AM, Kevin Smith wrote:
In the modules strawman, module is a keyword, right? Will code that
uses module as an identifier most likely cause a syntax error?
Thanks!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modules Question
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 (http://github.com/mozilla/narcissus). I'll ping the list
when the pages are updated.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modules Question
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?
On Tue, Dec 28, 2010 at 1:30 PM, David Herman dher...@mozilla.com wrote:
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 (
http://github.com/mozilla/narcissus). I'll ping the list when the pages
are updated.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modules Question
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.
Dave
On Dec 28, 2010, at 10:41 AM, Kevin Smith wrote:
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?
On Tue, Dec 28, 2010 at 1:30 PM, David Herman dher...@mozilla.com wrote:
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
(http://github.com/mozilla/narcissus). I'll ping the list when the pages are
updated.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modules Question
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?
Kevin
On Tue, Dec 28, 2010 at 1:51 PM, David Herman dher...@mozilla.com wrote:
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.
Dave
On Dec 28, 2010, at 10:41 AM, Kevin Smith wrote:
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?
On Tue, Dec 28, 2010 at 1:30 PM, David Herman dher...@mozilla.com wrote:
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 (
http://github.com/mozilla/narcissus). I'll ping the list when the pages
are updated.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
