import { foo, bar } as obj from 'module

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Dec 15 18:47:01 UTC 2017


here we are trying to achieve this:

```js
import { x, y } as foo from "foo";
import { x, y } as bar from "bar";

// so that we have
foo.x();
foo.y();

// and bar
bar.x();
bar.y();

// but NO x, y in scope
```

if you export x and y in scope you gotta have conflicts/clashes, which if I
understand correctly, is exactly what this idea is trying to avoid.




On Fri, Dec 15, 2017 at 11:42 AM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> Yes, but how would that be any different from what you'd have to deal
> with normally?
>
> To clarify, I was basically proposing exposing both the MNSEO with all
> export members (like `* as foo`) as well as live bindings from the
> module, separately. Something along the lines of a combination of the
> two.
>
> FYI, this is what Haskell does with `import qualified Foo.Bar (x, y)
> as Foo`. It exposes the exports `x` and `y` as globals, and it exposes
> those *with everything else* under the `Foo` namespace. (Of course,
> this isn't the driving reason for my suggestion - I didn't think about
> that until now.)
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Fri, Dec 15, 2017 at 7:00 AM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > that wouldn't solve the issue we are trying to solve, because the
> desugared
> > version will have x, and y in scope, right?
> >
> > we are trying to avoid issues with name clashes. If the new syntax
> doesn't
> > solve that, it's not any more helpful than `import * as foo from "mod"`
> >
> > On Fri, Dec 15, 2017 at 3:17 AM, Isiah Meadows <isiahmeadows at gmail.com>
> > wrote:
> >>
> >> I see it as it should semantically be identical to this, short a
> duplicate
> >> module request avoided:
> >>
> >> ```js
> >> // Proposed
> >> import {x, y} as foo from "mod"
> >>
> >> // Desugared
> >> import * as foo from "mod"
> >> import {x, y} from "mod"
> >> ```
> >>
> >> (This includes the implication `x`/`foo.x` and `y`/`foo.y` are
> >> equivalent.)
> >>
> >>
> >> On Thu, Dec 14, 2017, 15:30 Andrea Giammarchi
> >> <andrea.giammarchi at gmail.com> wrote:
> >>>
> >>> I've just tried monkey patching all the scenarios I've
> >>> described/mentioned and it works right away.
> >>>
> >>> // x.js
> >>> export let x = 1;
> >>> setTimeout(() => x = 2, 2000);
> >>>
> >>> // module.js
> >>> import {x} from './x.js';
> >>> const obj = Object.defineProperty({}, 'x', {get() { return x; }});
> >>> export {x, obj};
> >>>
> >>> // index.js
> >>> import {x, obj} from './module.js';
> >>> console.log(x, obj.x);
> >>> setTimeout(() => console.log(x, obj.x), 3000);
> >>>
> >>> I see 1, 1 and then 2, 2 without using proxies or exotic objects.
> >>>
> >>> `{a, b, c} as obj` should really just avoid `a`, `b`, `c` scope
> pollution
> >>> and create those accessors in the `obj` constant object reference.
> >>>
> >>> Regards
> >>>
> >>>
> >>> On Thu, Dec 14, 2017 at 5:55 PM, Darien Valentine <
> valentinium at gmail.com>
> >>> wrote:
> >>>>
> >>>> @Andrea I think we are thinking along the same lines. I meant proxy
> with
> >>>> a lowercase p — what you described fits the bill.
> >>>>
> >>>> _______________________________________________
> >>>> es-discuss mailing list
> >>>> es-discuss at mozilla.org
> >>>> https://mail.mozilla.org/listinfo/es-discuss
> >>>>
> >>>
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171215/91620e28/attachment.html>


More information about the es-discuss mailing list