Module Execution Order

Sam Tobin-Hochstadt samth at ccs.neu.edu
Wed Apr 10 08:39:56 PDT 2013


On Wed, Apr 10, 2013 at 11:01 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>
>>
>> I'm not sure what prior critique you're referring to.
>
>
> Quite a while ago, I pointed out that concatenation would be difficult with
> nested modules, but I was operating under the assumption of interleaved
> execution:  https://gist.github.com/zenparsing/3892979

I think this transformation demonstrates why I prefer our current
approach more than nested modules.  See my fork at
https://gist.github.com/samth/5355676

>> Also, we no longer plan to include nested modules in ES6.
>
>
> Yeah, I don't like that.  : )  I tend to agree with Andreas that modules
> should have a lexical face.

I don't particularly want to have this discussion yet another time,
but (a) lexical modules as in our original design did not serve all
the required use cases and (b) the addition in the future of lexical
modules is not ruled out. Given the interest, it may be something
someone wants to propose for ES7.

>> Also^2, concatenation should simply require literally concatenating the
>> modules, with
>> `module "NAME" { ... }` wrappers with appropriate names based on the
>> file system (in the common case where development occurs in multiple
>> node-style files).
>
> But with nested modules (and topological execution order), a tool can easily
> create the bundle.  In fact, I think it would be more effective for a tool
> to perform that bundling transformation than to do it by hand.
>
> Is there any context or information that would be lost when transforming a
> `module "name"` module into a (hypothetical) nested module?  I can't really
> think of any at the moment...

I don't understand this question.  A tool can perform the bundling in
my gist above very easily.

Sam


More information about the es-discuss mailing list