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
