Standard modules - concept or concrete?

Brian Di Palma offler at
Sat Jun 8 11:00:31 PDT 2013

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.

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