import { foo, bar } as obj from 'module

Caridy Patiño caridy at
Thu Dec 14 17:50:16 UTC 2017

Ok, fair enough! grammar wise, it doesn’t seem impossible since we already have `* as ns`. We knew about the possibility of doing folding and tree shaking, but there was nothing practical when module syntax was approved, and at that point, importing a namespace was probably sufficient, but not anymore, I get that.

Few more questions before someone can champion this:

1. Assuming that this new syntax produces a exotic namespace object is not trivial, e.g.:

import { x, y } as foo1 from "foo";
import { x, y } as bar1 from "foo"; // what if we use { y, x } instead?
foo1 === bar1 ; // is this true or false?

the same question applies when these are coming from different modules, while for existing namespace objects, the answer is always `true`:

import * as foo2 from "foo";
import * as bar2 from "foo";
foo2 === bar2; // yields true

2. Exotic namespace objects are bound to a module and its exports, and they have a 1-1 relationship, while this new thing seems quite different: <>

What are the reasons for this new syntax to produce exotic objects? Keep in mind that we usually favor bindings over namespace objects for performance reason (although implementers could do some optimizations with namespace objects).

3. Will this new syntax have symmetry with the export statement as well? e.g.: `export { x, y } as foo from "foo";`


> On Dec 13, 2017, at 4:27 PM, Darien Valentine <valentinium at> wrote:
> > Those {} that you see in the export and import statements are not objects, it is just syntax. Yes, I know, people confuse them with objects, until they realize they aren’t. We probably should have chosen a different syntax to signal that it is a binding from the module’s environment record.
> Not sure about the other folks here, but I wasn’t under the impression that the braces were an object literal or a binding pattern — though obviously `* from 'foo'` does return the module namespace exotic object. The idea I think is that it would be useful to extend NamespaceImport to permit retrieving a filtered view of the MNSEO that exposes only the specified bindings. I see that it’s novel because (correct me if I’m wrong) the same MNSEO instance is returned for namespace imports across multiple importing modules and is observably the same reference; currently it’s just "create the first time, retrieve thereafter". So here we’d be explicitly requesting a new object even if the module instance is already loaded, yes — but presumably it would be a new MNSEO (or proxy thereof) with the usual binding semantics, not a pojo.
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list