import { foo, bar } as obj from 'module

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

import { foo, bar } as obj from 'module

Tiddo Langerak
In modern ES code, I love the named imports & exports since it allows us
to only import what we need. Tooling has jumped on this as well by
stripping out any exports that aren't used (treeshaking).

However, a big downside of named imports is that you lose any
"namespacing", which is especially relevant for generic
function/variable names. For example, `lodash` and `async` both export a
`map` function, and it isn't unlikely to use both packages in a single
project, or even a single module. This gives naming conflicts.

We currently have 2 options to resolve these conflicts:

- Alias individual imports:

     import { map as lodashMap } from 'lodash';
     import { map as asyncMap } from 'async';

- Replace with * import

     import * as _ from 'lodash';
     import * as async from 'async';

Neither option is ideal:

- Aliasing results in either inconsistent code (some imports are
prefixed, others aren't) or "smurfnaming". Prefixing is often also less
readable than namespacing, especially for longer names
(`lodashLastIndexOf` vs `lodash.lastIndexOf`).
- Star imports prevent treeshaking.

The solution to this seems simple enough: allow a group of named imports
to be aliased as a whole:

     import { map } as _ from 'lodash';
     _.map();

This preserves both "namespacing" and selective importing, giving the
best of both worlds.

To me this seems like such a no-brainer that I'm actually surprised that
this isn't possible already. Has something like this been considered at
some point? And what would be the downsides of this? Or is there just
too little interest in this?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

Tiddo Langerak
Thanks for pointing that out, I didn't know that (I should've tested my
assumptions). It seems that Webpack does the same.

The entire motivation behind selective namespaced imports relied on that
assumption, so if treeshaking works with * imports then I don't think
there's much use for this feature.

On 12/12/2017 09:51 AM, Ltrlg wrote:

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

Isiah Meadows-2
This `import { ... } as foo from "..."` proposal would be incredibly useful. There's been times where I frequently used a single method from an import, but I only used the rest maybe once or twice, and thus didn't want to include *everything* when importing. It's easier than doing either duplicate imports or a subsequent `const foo = ns.foo` after the import.

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com

On Tue, Dec 12, 2017 at 3:19 AM, Tiddo Langerak <[hidden email]> wrote:
Thanks for pointing that out, I didn't know that (I should've tested my assumptions). It seems that Webpack does the same.

The entire motivation behind selective namespaced imports relied on that assumption, so if treeshaking works with * imports then I don't think there's much use for this feature.

On 12/12/2017 09:51 AM, Ltrlg wrote:
2017-12-12 8:39 GMT+01:00 Tiddo Langerak <[hidden email] <mailto:[hidden email]>>:

    - Star imports prevent treeshaking.


Treeshaking does work with star imports as long as you only have statically known usages. At least Rollup handles these situations as if it was a named import [1]

[1]: https://rollupjs.org/repl?version=0.52.1&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMColMjBhcyUyMG1hdGglMjBmcm9tJTIwJy4lMkZtYXRocy5qcyclM0IlNUNuY29uc29sZS5sb2coJTIwbWF0aC5jdWJlKCUyMDUlMjApJTIwKSUzQiUyMCUyRiUyRiUyMDEyNSUyMiU3RCUyQyU3QiUyMm5hbWUlMjIlM0ElMjJtYXRocy5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjBmdW5jdGlvbiUyMHNxdWFyZSUyMCglMjB4JTIwKSUyMCU3QiU1Q24lNUN0cmV0dXJuJTIweCUyMColMjB4JTNCJTVDbiU3RCU1Q24lNUNuZXhwb3J0JTIwZnVuY3Rpb24lMjBjdWJlJTIwKCUyMHglMjApJTIwJTdCJTVDbiU1Q3RyZXR1cm4lMjB4JTIwKiUyMHglMjAqJTIweCUzQiU1Q24lN0QlMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyY2pzJTIyJTJDJTIyZ2xvYmFscyUyMiUzQSU3QiU3RCUyQyUyMm5hbWUlMjIlM0ElMjJteUJ1bmRsZSUyMiUyQyUyMmFtZCUyMiUzQSU3QiUyMmlkJTIyJTNBJTIyJTIyJTdEJTdEJTJDJTIyZXhhbXBsZSUyMiUzQW51bGwlN0Q=

Ltrlg


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

Andrea Giammarchi-2
FWIW I agree `import {a, b} as mod from './module.js'` makes sense and it's handy.

I actually thought it was already possible and failed already a couple of time with that expectation.

Regards

On Tue, Dec 12, 2017 at 1:51 PM, Isiah Meadows <[hidden email]> wrote:
This `import { ... } as foo from "..."` proposal would be incredibly useful. There's been times where I frequently used a single method from an import, but I only used the rest maybe once or twice, and thus didn't want to include *everything* when importing. It's easier than doing either duplicate imports or a subsequent `const foo = ns.foo` after the import.

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com

On Tue, Dec 12, 2017 at 3:19 AM, Tiddo Langerak <[hidden email]> wrote:
Thanks for pointing that out, I didn't know that (I should've tested my assumptions). It seems that Webpack does the same.

The entire motivation behind selective namespaced imports relied on that assumption, so if treeshaking works with * imports then I don't think there's much use for this feature.

On 12/12/2017 09:51 AM, Ltrlg wrote:
2017-12-12 8:39 GMT+01:00 Tiddo Langerak <[hidden email] <mailto:[hidden email]>>:

    - Star imports prevent treeshaking.


Treeshaking does work with star imports as long as you only have statically known usages. At least Rollup handles these situations as if it was a named import [1]

[1]: https://rollupjs.org/repl?version=0.52.1&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMColMjBhcyUyMG1hdGglMjBmcm9tJTIwJy4lMkZtYXRocy5qcyclM0IlNUNuY29uc29sZS5sb2coJTIwbWF0aC5jdWJlKCUyMDUlMjApJTIwKSUzQiUyMCUyRiUyRiUyMDEyNSUyMiU3RCUyQyU3QiUyMm5hbWUlMjIlM0ElMjJtYXRocy5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjBmdW5jdGlvbiUyMHNxdWFyZSUyMCglMjB4JTIwKSUyMCU3QiU1Q24lNUN0cmV0dXJuJTIweCUyMColMjB4JTNCJTVDbiU3RCU1Q24lNUNuZXhwb3J0JTIwZnVuY3Rpb24lMjBjdWJlJTIwKCUyMHglMjApJTIwJTdCJTVDbiU1Q3RyZXR1cm4lMjB4JTIwKiUyMHglMjAqJTIweCUzQiU1Q24lN0QlMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyY2pzJTIyJTJDJTIyZ2xvYmFscyUyMiUzQSU3QiU3RCUyQyUyMm5hbWUlMjIlM0ElMjJteUJ1bmRsZSUyMiUyQyUyMmFtZCUyMiUzQSU3QiUyMmlkJTIyJTNBJTIyJTIyJTdEJTdEJTJDJTIyZXhhbXBsZSUyMiUzQW51bGwlN0Q=

Ltrlg


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Darien Valentine
In reply to this post by Tiddo Langerak
> To me this seems like such a no-brainer that I'm actually surprised that this isn't possible already.

I think it’s a no-brainer now that we’ve all been using import/export in practice for a while, but it’s understandable that it might not have been obvious on the first pass.

I don’t know how much of a factor this is in language design, but I think this addition could have a nice side effect — it might help encourage patterns that happen to play well with "tree shaking".

I bet this would fly if proposed!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

kai zhu
> I don’t know how much of a factor this is in language design, but I think this addition could have a nice side effect — it might help encourage patterns that happen to play well with "tree shaking".


tree-shaking is incompatible with class-inheritance and meta-programming in javascript.  it has negligible effect in practice, unless the majority of your code uses static-functions instead of classes.

> On Dec 13, 2017, at 2:46 AM, Darien Valentine <[hidden email]> wrote:
>
> > To me this seems like such a no-brainer that I'm actually surprised that this isn't possible already.
>
> I think it’s a no-brainer now that we’ve all been using import/export in practice for a while, but it’s understandable that it might not have been obvious on the first pass.
>
> I don’t know how much of a factor this is in language design, but I think this addition could have a nice side effect — it might help encourage patterns that happen to play well with "tree shaking".
>
> I bet this would fly if proposed!
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Darien Valentine
In reply to this post by Tiddo Langerak
> tree-shaking is incompatible with class-inheritance and meta-programming in javascript. it has negligible effect in practice, unless the majority of your code uses static-functions instead of classes.

It’s just a form of dead code elimination that takes advantage of the fact that imports/export statements are static. More often useful for library code than local app code (since if you had unused stuff there, you’d likely just delete it). I’m pretty perplexed by the suggestion that it has any sort of relationship with classes or inheritance. Are we talking about different things?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

kai zhu

we're talking about the same thing. class-based libraries like backbone.js for example cannot be tree-shaken.  i've done manual tree-shaking for the entire frontend-stack for swagger-ui, by writing tests and doing deadcode-elimination from code-coverage.  the takeaway from that was most of its libraries could not be tree-shaken, until the underlying class methods and constructors were manually refactored into separable static-functions.


On Dec 13, 2017 12:08 PM, "Darien Valentine" <[hidden email]> wrote:
> tree-shaking is incompatible with class-inheritance and meta-programming in javascript. it has negligible effect in practice, unless the majority of your code uses static-functions instead of classes.

It’s just a form of dead code elimination that takes advantage of the fact that imports/export statements are static. More often useful for library code than local app code (since if you had unused stuff there, you’d likely just delete it). I’m pretty perplexed by the suggestion that it has any sort of relationship with classes or inheritance. Are we talking about different things?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Giancarlo Anemone

Kai, I believe you are confusing classes with modules. A module can have many exports. For example, you could export 5 different classes from a single module. If you only import one of those classes, tree shaking ensures you don't include the other 4 unused Classes.

I think what you might be referring to is that tree shaking can't eliminate methods on a class that are potentially not called by a user. However that by no means makes tree shaking not valuable even when using libraries that export classes.

Finally, in my personal experience the amount of performance improvements you can make from dead code elimination are far from negligible. Of course it depends on many factors, but it is an incredibly useful feature.


On Tue, Dec 12, 2017, 9:54 PM kai zhu <[hidden email]> wrote:

we're talking about the same thing. class-based libraries like backbone.js for example cannot be tree-shaken.  i've done manual tree-shaking for the entire frontend-stack for swagger-ui, by writing tests and doing deadcode-elimination from code-coverage.  the takeaway from that was most of its libraries could not be tree-shaken, until the underlying class methods and constructors were manually refactored into separable static-functions.


On Dec 13, 2017 12:08 PM, "Darien Valentine" <[hidden email]> wrote:
> tree-shaking is incompatible with class-inheritance and meta-programming in javascript. it has negligible effect in practice, unless the majority of your code uses static-functions instead of classes.

It’s just a form of dead code elimination that takes advantage of the fact that imports/export statements are static. More often useful for library code than local app code (since if you had unused stuff there, you’d likely just delete it). I’m pretty perplexed by the suggestion that it has any sort of relationship with classes or inheritance. Are we talking about different things?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Dante Federici
In reply to this post by Tiddo Langerak
Definitely make a proposal for this -- I'm pretty tired of colliding utility function names and having to aggressively namespace them.

It's been said but I want to just throw in another voice that this will 100% work with tree shaking, and as we get better at organizing our modules and dependencies, it'll become more apparent.

With all the pushes toward pure functional code, utility modules and libraries will benefit more and more from tree shaking and clear / strong import/export syntax.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

Caridy Patino
those {} that you see in the export and import statements are not objects, it is just syntax. Yes, I know, people confuse them with objects, until they realize they aren’t. We probably should have chosen a different syntax to signal that it is a binding from the module’s environment record.

Another way to look at this is from the lenses of function declarations or function expressions, those {} that represent the body of the function are more closely related to what you use in the import/export statements that what you use for objects.

For those assuming that this will just fly through the staging process, it will not! There are many issues when considering it a object declaration.

/caridy

> On Dec 13, 2017, at 2:07 PM, dante federici <[hidden email]> wrote:
>
> Definitely make a proposal for this -- I'm pretty tired of colliding utility function names and having to aggressively namespace them.
>
> It's been said but I want to just throw in another voice that this will 100% work with tree shaking, and as we get better at organizing our modules and dependencies, it'll become more apparent.
>
> With all the pushes toward pure functional code, utility modules and libraries will benefit more and more from tree shaking and clear / strong import/export syntax.
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Darien Valentine
In reply to this post by Tiddo Langerak
> Those {} that you see in the export and import statements are not objects, it is just syntax. Yes, I know, people confuse them with objects, until they realize they aren’t. We probably should have chosen a different syntax to signal that it is a binding from the module’s environment record.

Not sure about the other folks here, but I wasn’t under the impression that the braces were an object literal or a binding pattern — though obviously `* from 'foo'` does return the module namespace exotic object. The idea I think is that it would be useful to extend NamespaceImport to permit retrieving a filtered view of the MNSEO that exposes only the specified bindings. I see that it’s novel because (correct me if I’m wrong) the same MNSEO instance is returned for namespace imports across multiple importing modules and is observably the same reference; currently it’s just "create the first time, retrieve thereafter". So here we’d be explicitly requesting a new object even if the module instance is already loaded, yes — but presumably it would be a new MNSEO (or proxy thereof) with the usual binding semantics, not a pojo.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Andrea Giammarchi-2
but I wasn’t under the impression that the braces were an object literal or a binding pattern

I think nobody thought that, we all assumed destructuring into a namespace.

import * as name from "module-name";
import { export } from "module-name";
the first is an import "everything" from module and the second destructures export from the module exports.

import { export } as name from "module" would destructure `export` and save it as name.export.

It's like having a namespace and use destructuring to address it.

We cannot:

const name = {};
import { export: name.export } from "module"

so that 

import { a, b, c } as name from "module"

seems to be the easiest way to go/explain/use namespaces as import.






On Wed, Dec 13, 2017 at 7:27 PM, Darien Valentine <[hidden email]> wrote:
> Those {} that you see in the export and import statements are not objects, it is just syntax. Yes, I know, people confuse them with objects, until they realize they aren’t. We probably should have chosen a different syntax to signal that it is a binding from the module’s environment record.

Not sure about the other folks here, but I wasn’t under the impression that the braces were an object literal or a binding pattern — though obviously `* from 'foo'` does return the module namespace exotic object. The idea I think is that it would be useful to extend NamespaceImport to permit retrieving a filtered view of the MNSEO that exposes only the specified bindings. I see that it’s novel because (correct me if I’m wrong) the same MNSEO instance is returned for namespace imports across multiple importing modules and is observably the same reference; currently it’s just "create the first time, retrieve thereafter". So here we’d be explicitly requesting a new object even if the module instance is already loaded, yes — but presumably it would be a new MNSEO (or proxy thereof) with the usual binding semantics, not a pojo.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Andrea Giammarchi-2
... sorry, I meant:

import { export as name.export } from "module"

which still is not possible.

import { export } as name from "module"

could also be compatible with live bindings too, so it seems like a win/win however you look at it



On Wed, Dec 13, 2017 at 9:11 PM, Andrea Giammarchi <[hidden email]> wrote:
but I wasn’t under the impression that the braces were an object literal or a binding pattern

I think nobody thought that, we all assumed destructuring into a namespace.

import * as name from "module-name";
import { export } from "module-name";
the first is an import "everything" from module and the second destructures export from the module exports.

import { export } as name from "module" would destructure `export` and save it as name.export.

It's like having a namespace and use destructuring to address it.

We cannot:

const name = {};
import { export: name.export } from "module"

so that 

import { a, b, c } as name from "module"

seems to be the easiest way to go/explain/use namespaces as import.






On Wed, Dec 13, 2017 at 7:27 PM, Darien Valentine <[hidden email]> wrote:
> Those {} that you see in the export and import statements are not objects, it is just syntax. Yes, I know, people confuse them with objects, until they realize they aren’t. We probably should have chosen a different syntax to signal that it is a binding from the module’s environment record.

Not sure about the other folks here, but I wasn’t under the impression that the braces were an object literal or a binding pattern — though obviously `* from 'foo'` does return the module namespace exotic object. The idea I think is that it would be useful to extend NamespaceImport to permit retrieving a filtered view of the MNSEO that exposes only the specified bindings. I see that it’s novel because (correct me if I’m wrong) the same MNSEO instance is returned for namespace imports across multiple importing modules and is observably the same reference; currently it’s just "create the first time, retrieve thereafter". So here we’d be explicitly requesting a new object even if the module instance is already loaded, yes — but presumably it would be a new MNSEO (or proxy thereof) with the usual binding semantics, not a pojo.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

Caridy Patino
In reply to this post by Darien Valentine
Ok, fair enough! grammar wise, it doesn’t seem impossible since we already have `* as ns`. We knew about the possibility of doing folding and tree shaking, but there was nothing practical when module syntax was approved, and at that point, importing a namespace was probably sufficient, but not anymore, I get that.

Few more questions before someone can champion this:

1. Assuming that this new syntax produces a exotic namespace object is not trivial, e.g.:

```
import { x, y } as foo1 from "foo";
import { x, y } as bar1 from "foo"; // what if we use { y, x } instead?
foo1 === bar1 ; // is this true or false?
```

the same question applies when these are coming from different modules, while for existing namespace objects, the answer is always `true`:

import * as foo2 from "foo";
import * as bar2 from "foo";
foo2 === bar2; // yields true

2. Exotic namespace objects are bound to a module and its exports, and they have a 1-1 relationship, while this new thing seems quite different: https://tc39.github.io/ecma262/#sec-module-namespace-exotic-objects

What are the reasons for this new syntax to produce exotic objects? Keep in mind that we usually favor bindings over namespace objects for performance reason (although implementers could do some optimizations with namespace objects).

3. Will this new syntax have symmetry with the export statement as well? e.g.: `export { x, y } as foo from "foo";`

/caridy

On Dec 13, 2017, at 4:27 PM, Darien Valentine <[hidden email]> wrote:

> Those {} that you see in the export and import statements are not objects, it is just syntax. Yes, I know, people confuse them with objects, until they realize they aren’t. We probably should have chosen a different syntax to signal that it is a binding from the module’s environment record.

Not sure about the other folks here, but I wasn’t under the impression that the braces were an object literal or a binding pattern — though obviously `* from 'foo'` does return the module namespace exotic object. The idea I think is that it would be useful to extend NamespaceImport to permit retrieving a filtered view of the MNSEO that exposes only the specified bindings. I see that it’s novel because (correct me if I’m wrong) the same MNSEO instance is returned for namespace imports across multiple importing modules and is observably the same reference; currently it’s just "create the first time, retrieve thereafter". So here we’d be explicitly requesting a new object even if the module instance is already loaded, yes — but presumably it would be a new MNSEO (or proxy thereof) with the usual binding semantics, not a pojo.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

Andrea Giammarchi-2
I see the following:

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

as the pseudo equivalent of:

```js
import {x, y} from "foo";
const foo1 = {
  // live bindings survive
  get x() { return x; },
  get y() { return y; }
};
// but x and y never happened
// (pseudo-operation)
delete scope references {x, y};
```

Accordingly, these are my answers:

1. foo1 === bar1 is false, no exotic object whatsoever. It's a namespace with getters (that could eventually be enriched a part)
2. no need for exotic objects
3. `export { x, y } as foo from "foo";` will export a `foo` object with `x` and `y` accessors. It'd be possible to `import {foo} from "foo"` so the answer to the third point is yes.

Regards






On Thu, Dec 14, 2017 at 3:50 PM, Caridy Patiño <[hidden email]> wrote:
Ok, fair enough! grammar wise, it doesn’t seem impossible since we already have `* as ns`. We knew about the possibility of doing folding and tree shaking, but there was nothing practical when module syntax was approved, and at that point, importing a namespace was probably sufficient, but not anymore, I get that.

Few more questions before someone can champion this:

1. Assuming that this new syntax produces a exotic namespace object is not trivial, e.g.:

```
import { x, y } as foo1 from "foo";
import { x, y } as bar1 from "foo"; // what if we use { y, x } instead?
foo1 === bar1 ; // is this true or false?
```

the same question applies when these are coming from different modules, while for existing namespace objects, the answer is always `true`:

import * as foo2 from "foo";
import * as bar2 from "foo";
foo2 === bar2; // yields true

2. Exotic namespace objects are bound to a module and its exports, and they have a 1-1 relationship, while this new thing seems quite different: https://tc39.github.io/ecma262/#sec-module-namespace-exotic-objects

What are the reasons for this new syntax to produce exotic objects? Keep in mind that we usually favor bindings over namespace objects for performance reason (although implementers could do some optimizations with namespace objects).

3. Will this new syntax have symmetry with the export statement as well? e.g.: `export { x, y } as foo from "foo";`

/caridy

On Dec 13, 2017, at 4:27 PM, Darien Valentine <[hidden email]> wrote:

> Those {} that you see in the export and import statements are not objects, it is just syntax. Yes, I know, people confuse them with objects, until they realize they aren’t. We probably should have chosen a different syntax to signal that it is a binding from the module’s environment record.

Not sure about the other folks here, but I wasn’t under the impression that the braces were an object literal or a binding pattern — though obviously `* from 'foo'` does return the module namespace exotic object. The idea I think is that it would be useful to extend NamespaceImport to permit retrieving a filtered view of the MNSEO that exposes only the specified bindings. I see that it’s novel because (correct me if I’m wrong) the same MNSEO instance is returned for namespace imports across multiple importing modules and is observably the same reference; currently it’s just "create the first time, retrieve thereafter". So here we’d be explicitly requesting a new object even if the module instance is already loaded, yes — but presumably it would be a new MNSEO (or proxy thereof) with the usual binding semantics, not a pojo.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Darien Valentine
In reply to this post by Tiddo Langerak
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

Caridy Patino
inline

> On Dec 14, 2017, at 2:29 PM, Darien Valentine <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import { foo, bar } as obj from 'module

Andrea Giammarchi-2
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 <[hidden email]> wrote:
inline

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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import { foo, bar } as obj from 'module

Darien Valentine
In reply to this post by Tiddo Langerak
@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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12