On Sat, Jun 8, 2013 at 2:00 PM, Brian Di Palma <[email protected]> wrote: > Good, I like the standard modules idea. > > On Sat, Jun 8, 2013 at 2:33 PM, Sam Tobin-Hochstadt <[email protected]> wrote: >> >> The global object will still be accessible in modules. Of course, you >> can create new module loaders with an empty global. >> > > Umm. It makes porting old code easier. > > If we could guarantee that any reference inside a module had to have > an import definition I imagine IDEs and development concatenation > tools would provide > fast feedback when those rules are broken. Why would people use the > standard modules if they can just access the global? > > Is it expected that developers import things like Date because it > would be good practice? > > import { Date } from "@std"; > > or simply > > new Date(); > > I can imagine many people just taking option 2. Seem to make standard > modules somewhat redundant, or at least it undermines them. > I suppose then the static checks are only to check that a module > imports the identifiers that another module exports, is that it? > If we can grab anything from the global that means un-imported > references can be used all over module code and the environment will > just have > to shrug its shoulders an accept it. No compile time error. Somewhat > disappointed with that.
I think you misunderstand. The requirement that modules not have free variables at compile time *includes* global references. I expect that development environments won't have a problem handling this or enforcing whatever properties you're looking for. > > So modules will be allowed to be polluted by the global state, not > just build in globals but any possible user defined global state. > > The possibility of strengthening module consistency is off the table? _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
