import { foo, bar } as obj from 'module

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Dec 14 19:06:08 UTC 2017


I see the following:

```js
import { x, y } as foo1 from "foo";
```

as the pseudo equivalent of:

```js
import {x, y} from "foo";
const foo1 = {
  // live bindings survive
  get x() { return x; },
  get y() { return y; }
};
// but x and y never happened
// (pseudo-operation)
delete scope references {x, y};
```

Accordingly, these are my answers:

1. foo1 === bar1 is false, no exotic object whatsoever. It's a namespace
with getters (that could eventually be enriched a part)
2. no need for exotic objects
3. `export { x, y } as foo from "foo";` will export a `foo` object with `x`
and `y` accessors. It'd be possible to `import {foo} from "foo"` so the
answer to the third point is yes.

Regards






On Thu, Dec 14, 2017 at 3:50 PM, Caridy Patiño <caridy at gmail.com> wrote:

> 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
>
> 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 <valentinium at gmail.com>
> 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171214/20bf956b/attachment-0001.html>


More information about the es-discuss mailing list