Standard modules - concept or concrete?

Sam Tobin-Hochstadt samth at
Sat Jun 8 11:07:17 PDT 2013

On Sat, Jun 8, 2013 at 2:00 PM, Brian Di Palma <offler at> wrote:
> Good, I like the standard modules idea.
> On Sat, Jun 8, 2013 at 2:33 PM, Sam Tobin-Hochstadt <samth at> 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?

More information about the es-discuss mailing list