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.
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. 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. I definitely don’t have the perspective to see how these ideas would be good or bad for implementors, so I may be on the wrong track, not sure. (BTW, when I said I thought this "would fly", I meant it in the idiomatic sense "be viable", rather than that it "would have no considerations or concerns" haha)
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss