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 <[email protected]> wrote: > inline > > > On Dec 14, 2017, at 2:29 PM, Darien Valentine <[email protected]> > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
