import { foo, bar } as obj from 'module

Caridy Patiño caridy at
Thu Dec 14 19:39:14 UTC 2017


> On Dec 14, 2017, at 2:29 PM, Darien Valentine <valentinium at> wrote:
> 1. (Caching of same-subset namespace import) My gut feeling was that the simplest thing to do would be to treat `import { x, y } as foo from 'foo';` as _always_ creating a new MNSEO or — more likely? — not an MNSEO directly, but a proxy of it whose only job is to filter access. That is, internally there would still be a "complete" MNSEO. So even within a single module, I would expect `import { x, y } as foo from 'foo'; import { x, y } as bar from 'foo'; assert(foo !== bar);` My main reason for thinking this is that it’s less complex that maintaining a cache keyed on what was imported, and it doesn’t seem that a caching behavior would provide any useful advantages.

No proxies please! those are another kind of exotic objects, and it will just complicate even more this feature request. Think about this as records of some sort based on what you’re importing and from where. The semantic to be figure here is how do they behave across modules when they are exported. We need a better answer here.

> 2. (Potential conflict with current definitions of MNSEO model / behavior) I agree, this does seem different, which is why I’d suggest the value be a proxy of some sort. If it proxies the same underlying MNSEO, I’m pretty sure MNSEO’s existing 1:1 behavior would be affected.

same as above.

> 3. (Export symmetry) That’s interesting — yeah, it would make sense to honor the contract; `import * as ns from "foo";` is permitted, and `export { foo, bar } as baz;` would not be equivalent to `export const baz = { foo, bar };` since only the former would keep live bindings.

We need to think more about this. The semantic to be figure here is whether or not `{ x, y } as foo` should use live bindings, and that will help to clarify few things.


More information about the es-discuss mailing list