import { foo, bar } as obj from 'module

Andrea Giammarchi andrea.giammarchi at
Thu Dec 14 19:46:25 UTC 2017

if you `import {x} from "foo"` and `x` changes in foo, then `x` reflects
changes in the module that imported it.
if you `import {x} as foo from "foo"` I'd expect the same and my answer was
making it possible, without using Proxies, right?

not sure why you're fully skipping my proposed solution here

On Thu, Dec 14, 2017 at 5:39 PM, Caridy Patiño <caridy at> wrote:

> inline
> > 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.
> /caridy
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list