import { foo, bar } as obj from 'module

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Dec 13 23:35:32 UTC 2017


... 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 <
andrea.giammarchi at gmail.com> 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 <valentinium at gmail.com>
> 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
>> 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/20171213/e4b4d7e5/attachment.html>


More information about the es-discuss mailing list