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:
https://tc39.github.io/ecma262/#sec-module-namespace-exotic-objects
<https://tc39.github.io/ecma262/#sec-module-namespace-exotic-objects>
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";`
/caridy
> On Dec 13, 2017, at 4:27 PM, Darien Valentine <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
