Yes, exactly. Of course, running a module can load other modules using the Loaders API, but that doesn't add any new imports or exports to the module itself.
Sam On Nov 18, 2013 8:54 AM, "Brian Di Palma" <off...@gmail.com> wrote: > You can statically analyze the module text and enumerate the complete > imports and exports of the module without having to execute the module. The > execution of the module will not dynamically increase it's imports/exports. > > For instance could you have a Math.random that decides if a dependency is > required? > On Nov 18, 2013 1:33 PM, "Sam Tobin-Hochstadt" <sa...@cs.indiana.edu> > wrote: > >> >> On Nov 18, 2013 7:17 AM, "Brian Di Palma" <off...@gmail.com> wrote: >> > >> > Correct me if I'm wrong David but module import/exports are not >> > dynamic which allows tooling/IDEs to be more intelligent and >> > programmers to easily understand what dependencies a module >> > has/provides? >> >> Yes, that's correct, if I guess correctly at what you mean by dynamic. >> >> Sam >> >> > On Sat, Nov 16, 2013 at 8:30 AM, David Herman <dher...@mozilla.com> >> wrote: >> > > On Nov 16, 2013, at 3:32 AM, John Barton <johnjbar...@google.com> >> wrote: >> > > >> > >> Could someone help me understand why two goals for parsing JS is a >> good thing? >> > > >> > > Hm, it sounds like you've assumed a conclusion already. Let me try to >> explain anyway. >> > > >> > > Scripts are for synchronous loading and evaluation; modules are for >> asynchronous loading and evaluation. The former is not allowed to import, >> which triggers I/O. The latter is allowed to import. There was always going >> to have to be a syntactic split. >> > > >> > > But there's more. I'll be explaining at this week's TC39 meeting some >> more details about the intended model for browser integration. In short, >> declarative code based on modules will use the <module> tag (or <script >> type="module">, which will mean the same thing and allows polyfilling >> today). This is better than <script async>, which was a hopeless idea. This >> also works beautifully for fulfilling the promise of 1JS: a new, better >> initial environment in which to run top-level application code without >> requiring versioning. >> > > >> > > <module> >> > > var x = 12; // local to this module, not exported >> on global object >> > > import $ from "jquery"; // asynchronous dependency, NBD >> > > '$' in this // nope, because all globals are scoped >> to this module >> > > let y = 13; // yep, let works great because modules >> are strict >> > > </module> >> > > >> > > Same number of characters as <script>, better semantics, better >> global environment, better language. >> > > >> > > If you're not excited about ES6 yet, get excited. :) >> > > >> > > Dave >> > > >> > > _______________________________________________ >> > > 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 >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
