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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171214/37b26676/attachment.html>

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 than 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 unaffected.

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)

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 than 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)