Modules Question

[David Herman]

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.)

Dave

On Dec 28, 2010, at 11:17 AM, Kevin Smith wrote:

> 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 <dherman at 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 <dherman at 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 at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101228/f922d11b/attachment.html>