Re: ES6 module syntax – done?
yes, we just don't know yet, we have to think about it. there is already a good
discussion happening about the loader shim we plan to provide, etc. look into
the loader repo.
Sent from my iPhone
> On Mar 21, 2015, at 6:14 PM, James Kyle wrote:
>
> >
> > There was then discussion of how to get module metadata, with Dave's
> > initial proposal per his slides being this (as Juan shows). However, we
> > eventually arrived at the idea of
> >
> > import { name, url } from this module;
> >
>
> Would it make more sense to add additional meta properties in ES7 for
> import/export metadata?
>
> ie.
>
> ```
> export.name // name of the current module
> export.address // location of the current module
> export.metadata // object with metadata generated during the loading lifecycle
> export.loader // maybe? reference to the loader that actually loaded this
> module
> ```
>
>
>
>> On Sat, Mar 21, 2015 at 12:53 PM, Kyle Simpson wrote:
>> Just for posterity sake, since I got tripped up here…
>>
>> `import .. from this module` did not make it into ES6. It may come in later,
>> in that form or some other.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 module syntax – done?
that is correct. Sent from my iPhone > On Mar 21, 2015, at 3:52 PM, Kyle Simpson wrote: > > Just for posterity sake, since I got tripped up here… > > `import .. from this module` did not make it into ES6. It may come in later, > in that form or some other. > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 module syntax – done?
>
> There was then discussion of how to get module metadata, with Dave's initial
> proposal per his slides being this (as Juan shows). However, we eventually
> arrived at the idea of
>
> import { name, url } from this module;
>
Would it make more sense to add additional meta properties in ES7 for
import/export metadata?
ie.
```
export.name // name of the current module
export.address // location of the current module
export.metadata // object with metadata generated during the loading lifecycle
export.loader // maybe? reference to the loader that actually loaded this module
```
On Sat, Mar 21, 2015 at 12:53 PM, Kyle Simpson wrote:
> Just for posterity sake, since I got tripped up here…
> `import .. from this module` did not make it into ES6. It may come in later,
> in that form or some other.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 module syntax – done?
Just for posterity sake, since I got tripped up here… `import .. from this module` did not make it into ES6. It may come in later, in that form or some other. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 module syntax – done?
Thanks, Domenic. Very helpful! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: ES6 module syntax – done?
Was just going through updating @esdiscuss when I noticed nobody really
answered this thread. Which is lame.
The meeting notes at [1] are hard to interpret given that the slides are still
MIA (Dave?). But essentially, import-into-namespace syntax is now `import * as
x from "y"`, replacing the previous `module x from "y"`.
There was then discussion of how to get module metadata, with Dave's initial
proposal per his slides being `this` (as Juan shows). However, we eventually
arrived at the idea of
import { name, url } from this module;
(with `this module` being bikesheddable, but everyone more or less liked that.)
As the notes show, you could also do e.g. `import * as me from this module` and
then use `me.name` and so on.
[1]:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#45-import-into-namespace-syntax-dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 module syntax – done?
There was discussion about using `this` for exposing metadata about the module. For example (pure speculation): this.address; // location of the current module this.name; // name of the current module this.metadata; // object with metadata generated during the loading lifecycle this.loader // maybe? reference to the loader that actually loaded this module -Juan On Wednesday, August 6, 2014 3:31 PM, Axel Rauschmayer wrote: I haven’t seen any mention of `import * as foo` in the meeting notes, so I’m assuming that the ES6 module syntax is basically done. Right? Except for the “import-into-namespace syntax” [1], of course. As an aside, I’m really glad that `this` won’t be used here (which would have resulted in yet another thing one has to learn about `this`). [1] https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#45-import-into-namespace-syntax-dave -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ES6 module syntax – done?
I haven’t seen any mention of `import * as foo` in the meeting notes, so I’m assuming that the ES6 module syntax is basically done. Right? Except for the “import-into-namespace syntax” [1], of course. As an aside, I’m really glad that `this` won’t be used here (which would have resulted in yet another thing one has to learn about `this`). [1] https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#45-import-into-namespace-syntax-dave -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
>
> export let default = 17;
> export default = 17;
> export default = function f() { ... };
> export default = class { ... };
> export function default(...) { ... }
> export class default { ... }
>
>
Interesting, but whether we go the other forms or not, I'm sold on this
simple desugaring of defaults. Looking good! : )
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Jun 6, 2013, at 11:05 AM, Axel Rauschmayer wrote: > OK, so you don’t want to replace > > import foo from "single_export_module"; > > with (braceless!) > > import default as foo from "single_export_module"; That's correct, I don't want to use `import default`. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Jun 6, 2013, at 19:42 , David Herman wrote:
> On Jun 5, 2013, at 3:59 PM, Axel Rauschmayer wrote:
>
>> This makes a lot of sense. It would obviate the need for braces, right?
>
> No, at least not for imports. This is only about exports. I'd argue we should
> keep the braces on export { x, y, z } for symmetry with imports.
OK, so you don’t want to replace
import foo from "single_export_module";
with (braceless!)
import default as foo from "single_export_module";
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Jun 5, 2013, at 2:58 PM, Domenic Denicola
wrote:
> From: David Herman [dher...@mozilla.com]
>
>> Moreover, Yehuda has urged me to consider
>>
>> export x = 17;
>>
>> as sugar for
>>
>> export let x = 17;
>
> I'd urge `const` instead of `let`, as `const` discourages the footgun of
> action-at-a-distance mutable `with`/global-like bindings that I keep talking
> about (e.g. at http://esdiscuss.org/topic/importandaliasingbindings). Ideally
> this would extend to `function` and `class` as well.
This is too bondage-and-discipline for JS. If you simply don't multiply-assign
to the bindings they will be immutable anyway.
> In fact, if I had my way I'd continue down this path trying to eliminate
> mutable action-at-a-distance bindings entirely by removing `export let`,
> `export var`, and `export const`. That just leaves `let x; export { x };` as
> dangerous, and I think there are solutions to that but I won't bore you with
> them unless people are enthusiastic about this idea...
I'm not. :) I don't agree that the ability for a module to choose to export a
mutable binding is bad.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Jun 5, 2013, at 3:59 PM, Axel Rauschmayer wrote:
> This makes a lot of sense. It would obviate the need for braces, right?
No, at least not for imports. This is only about exports. I'd argue we should
keep the braces on export { x, y, z } for symmetry with imports.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
This makes a lot of sense. It would obviate the need for braces, right?
> Yes, this is actually the direction I've been going in my thinking, based on
> the critique that export default is the only export form that isn't a binding
> form, especially when combined with a named function literal (`export default
> function f() { ... }`). I also like the conceptual simplicity of the default
> export simply being a public export named "default". Moreover, Yehuda has
> urged me to consider
>
>export x = 17;
>
> as sugar for
>
>export let x = 17;
>
> When you put this all together, you can actually just see `export default =
> ...` as sugar for `export let default = ...`. We can also allow the keyword
> `default` to be used for the other exported declaration forms like `export
> function default(...) { ... }` and `export class default { ... }`. (We'll
> finesse the .name property of such a declared function to be taken from the
> module name, a la Brandon's accepted proposal for .name in ES6.) To recap,
> the following all become valid ways to specify the default export:
>
>export let default = 17;
>export default = 17;
>export default = function f() { ... };
>export default = class { ... };
>export function default(...) { ... }
>export class default { ... }
>
> And you can now import both the default and non-default exports of a module
> in a single line:
>
>import { default as $, ajax } from "jquery";
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Module syntax
From: David Herman [dher...@mozilla.com]
> Moreover, Yehuda has urged me to consider
>
>export x = 17;
>
> as sugar for
>
>export let x = 17;
I'd urge `const` instead of `let`, as `const` discourages the footgun of
action-at-a-distance mutable `with`/global-like bindings that I keep talking
about (e.g. at http://esdiscuss.org/topic/importandaliasingbindings). Ideally
this would extend to `function` and `class` as well. The desugarings then become
```js
export x = 17;
export function x() { };
export class x { };
```
to
```js
export const x = 17;
export const x = function x() { };
export const x = class x { };
```
In fact, if I had my way I'd continue down this path trying to eliminate
mutable action-at-a-distance bindings entirely by removing `export let`,
`export var`, and `export const`. That just leaves `let x; export { x };` as
dangerous, and I think there are solutions to that but I won't bore you with
them unless people are enthusiastic about this idea...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
I really like the way this sounds, just wanted to submit my approval :D
On Wed, Jun 5, 2013 at 12:37 PM, David Herman wrote:
> On Jun 5, 2013, at 11:51 AM, Kevin Smith wrote:
>
> > It occurs to me that this is valid under the current grammar:
> >
> > import { default as foo } from "foo";
> > export { foo as default };
> >
> > We've discussed using a well-known symbol for the default export, but
> this simple desugaring might be another option:
> >
> > import foo as "foo";
> > // => import { default as foo } from "foo";
> >
> > export default = expr;
> > // => let __genident__ = expr; export { __genident__ as default };
> >
> > This would provide easy access to the default export on a module
> instance object without having to obtain a reference to a symbol.
> >
> > module Foo from "foo";
> > F.default();
> >
> > Just throwing an idea out...
>
> Yes, this is actually the direction I've been going in my thinking, based
> on the critique that export default is the only export form that isn't a
> binding form, especially when combined with a named function literal
> (`export default function f() { ... }`). I also like the conceptual
> simplicity of the default export simply being a public export named
> "default". Moreover, Yehuda has urged me to consider
>
> export x = 17;
>
> as sugar for
>
> export let x = 17;
>
> When you put this all together, you can actually just see `export default
> = ...` as sugar for `export let default = ...`. We can also allow the
> keyword `default` to be used for the other exported declaration forms like
> `export function default(...) { ... }` and `export class default { ... }`.
> (We'll finesse the .name property of such a declared function to be taken
> from the module name, a la Brandon's accepted proposal for .name in ES6.)
> To recap, the following all become valid ways to specify the default export:
>
> export let default = 17;
> export default = 17;
> export default = function f() { ... };
> export default = class { ... };
> export function default(...) { ... }
> export class default { ... }
>
> And you can now import both the default and non-default exports of a
> module in a single line:
>
> import { default as $, ajax } from "jquery";
>
> Dave
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Jun 5, 2013, at 11:51 AM, Kevin Smith wrote:
> It occurs to me that this is valid under the current grammar:
>
> import { default as foo } from "foo";
> export { foo as default };
>
> We've discussed using a well-known symbol for the default export, but this
> simple desugaring might be another option:
>
> import foo as "foo";
> // => import { default as foo } from "foo";
>
> export default = expr;
> // => let __genident__ = expr; export { __genident__ as default };
>
> This would provide easy access to the default export on a module instance
> object without having to obtain a reference to a symbol.
>
> module Foo from "foo";
> F.default();
>
> Just throwing an idea out...
Yes, this is actually the direction I've been going in my thinking, based on
the critique that export default is the only export form that isn't a binding
form, especially when combined with a named function literal (`export default
function f() { ... }`). I also like the conceptual simplicity of the default
export simply being a public export named "default". Moreover, Yehuda has urged
me to consider
export x = 17;
as sugar for
export let x = 17;
When you put this all together, you can actually just see `export default =
...` as sugar for `export let default = ...`. We can also allow the keyword
`default` to be used for the other exported declaration forms like `export
function default(...) { ... }` and `export class default { ... }`. (We'll
finesse the .name property of such a declared function to be taken from the
module name, a la Brandon's accepted proposal for .name in ES6.) To recap, the
following all become valid ways to specify the default export:
export let default = 17;
export default = 17;
export default = function f() { ... };
export default = class { ... };
export function default(...) { ... }
export class default { ... }
And you can now import both the default and non-default exports of a module in
a single line:
import { default as $, ajax } from "jquery";
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
It occurs to me that this is valid under the current grammar:
import { default as foo } from "foo";
export { foo as default };
We've discussed using a well-known symbol for the default export, but this
simple desugaring might be another option:
import foo as "foo";
// => import { default as foo } from "foo";
export default = expr;
// => let __genident__ = expr; export { __genident__ as default };
This would provide easy access to the default export on a module instance
object without having to obtain a reference to a symbol.
module Foo from "foo";
F.default();
Just throwing an idea out...
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
Sorry - corrections to examples:
import foo from "foo";
// => import { default as foo } from "foo";
export default = expr;
// => let __genident__ = expr; export { __genident__ as default };
module Foo from "foo";
Foo.default();
Thanks,
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
`import foo from "foo";` reads to the quick eye as "import the symbol
named foo from the module named 'foo'" -- but that's not actually what
it means (wrapped curlies be damned!).
I think the syntax would read much less confusingly if we made use of a
`default` keyword to signify better what's happening in this declaration...
Anything from `import default foo from "foo"` to the more preferable (in
my mind) `import default as foo from "foo"`
On 6/3/13 7:07 PM, Kevin Smith wrote:
> Bikeshedding:
Well, here comes a fun thread...
Bikeshedding *is* fun : )
FWIW, I've implemented a parser for curly-free syntax and it does
introduce some minor parsing difficulties on the export side. If we
had lexical modules, then this:
export module as ...
could be a valid prefix for an exported module declaration or an
export set. You basically need more tokens of lookahead to
disambiguate on these contextual keywords.
I'm totally happy with the current syntax, modulo some concern over
the default export syntax which I mentioned upthread.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
>
> > Bikeshedding:
>
> Well, here comes a fun thread...
>
>
Bikeshedding *is* fun : )
FWIW, I've implemented a parser for curly-free syntax and it does introduce
some minor parsing difficulties on the export side. If we had lexical
modules, then this:
export module as ...
could be a valid prefix for an exported module declaration or an export
set. You basically need more tokens of lookahead to disambiguate on these
contextual keywords.
I'm totally happy with the current syntax, modulo some concern over the
default export syntax which I mentioned upthread.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Mon, Jun 3, 2013 at 1:55 PM, Juan Ignacio Dopazo
wrote:
> Now that it's been decided that braces are not a form of destructuring and
> the colon replaced with `as`, what's the benefit of using braces? Why not
> this previous proposal?
>
> import foo as foofoo from "foo";
>
> import "bar" as bar;
>
I'm predicting thousands of "why" here once it's shipped. Users will be
asking -- what the heck is going on here?
IM(h)O, it should be just:
import bar;
And that's it.
Below are some "syntax of my dreams" (not gonna bikeshead though):
Basic imports:
1. import foo; // imports exports of module foo and binds to foo; can be
used as foo.bar();
2. import "http://mysite.com/foo.js"; as foo; // imports foo from external
source, can be done only via aliasing to bind name;
3. import default foo; // import the default expression from module foo.
Aliasing:
4. import foo as myFoo;
5. import "http://mysite.com/foo.js"; as myFoo; // already mentioned
Import all bindings to the current ns:
6. import * from foo; // can be used then as bar(); baz();
7. import * from "http://mysite.com/foo.js; // the same
Import some of the methods:
8. import bar from foo; // imports only bar method from foo (w/ potential
syntax ambiguity and using {})
9. import {baz, bar} from foo; // ditto, two
10. import {baz: myBaz} from foo;
11. import bar from "http://mysite.com/foo.js";;
Please, please, please -- would be awesome to NOT using string names (if of
course possible):
module foo {} // doesn't matter whether it's lexical or not, but foo is
just a name
module foo/bar {} // namespaced name, OK, can be module 'foo/bar' {}
P.S.: Although, I don't like bikesheading threads and think it should be
prepared well with arguments and all implementation details before
discussions.
Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Jun 3, 2013, at 10:29 AM, Axel Rauschmayer wrote: > Bikeshedding: Well, here comes a fun thread... > Rationale: > – Reducing the grawlix factor. > – Making non-default imports more convenient – which I assume will happen > more often(?) That's what this comes down to: do you expect the common case to be small modules with a main export, or large modules with many named exports. We opted for the former, since there are many prominent libraries and communities in the JS world that have gravitated towards small modules. That said, the extra burden of two curly braces is very, very small. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Jun 3, 2013, at 1:55 PM, Juan Ignacio Dopazo wrote: > Now that it's been decided that braces are not a form of destructuring and > the colon replaced with `as`, what's the benefit of using braces? Why not > this previous proposal? > > import foo as foofoo from "foo"; > > import "bar" as bar; Because it's ambiguous with default import; without curly braces, a single named import, without the "as" renaming, would have indistinguishable syntax from importing the default export. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
Now that it's been decided that braces are not a form of destructuring and the colon replaced with `as`, what's the benefit of using braces? Why not this previous proposal? import foo as foofoo from "foo"; import "bar" as bar; Juan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
if
```
function x() {}
export default x;
```
works thought, that ain't any different from returning function expression
where you cannot reuse that function if not inside the function itself.
It does not look like a big lost but more similar to expression logic we
are use to with JS ... or, is it?
On Mon, Jun 3, 2013 at 1:03 PM, Kevin Smith wrote:
>
> `export default` is perfect IMO. It also conceptually fits better with how
>> default exports work. (I.e., they're *default* exports, they're not the
>> entirety of the exports. They don't overwrite the module instance object,
>> in the fashion that `module.exports =` does.)
>>
>>
> A potential problem with `export default` is that there is very little to
> signify (to humans) that we are entering an expression context. For
> example, the following "looks like" a declaration with a modifier, but it's
> not.
>
> export default function x() {}
> x(); // ReferenceError!
>
> It might be better to clearly indicate the expression context by a "=" or
> something similar.
>
> { Kevin }
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
+1 as soon as the syntax is slightly different from NPM/AMD makes sense to have less ambiguity and a better definition. export default looks good here too On Mon, Jun 3, 2013 at 12:57 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I really dislike `export =`. It looks like it should be creating a global > variable named `export`. > > `export default` is perfect IMO. It also conceptually fits better with how > default exports work. (I.e., they're *default* exports, they're not the > entirety of the exports. They don't overwrite the module instance object, > in the fashion that `module.exports =` does.) > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
> `export default` is perfect IMO. It also conceptually fits better with how
> default exports work. (I.e., they're *default* exports, they're not the
> entirety of the exports. They don't overwrite the module instance object,
> in the fashion that `module.exports =` does.)
>
>
A potential problem with `export default` is that there is very little to
signify (to humans) that we are entering an expression context. For
example, the following "looks like" a declaration with a modifier, but it's
not.
export default function x() {}
x(); // ReferenceError!
It might be better to clearly indicate the expression context by a "=" or
something similar.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Mon, Jun 3, 2013 at 3:57 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I really dislike `export =`. It looks like it should be creating a global > variable named `export`. > > `export default` is perfect IMO. It also conceptually fits better with how > default exports work. (I.e., they're *default* exports, they're not the > entirety of the exports. They don't overwrite the module instance object, > in the fashion that `module.exports =` does.) > Agreed. I was drafting a response when this came through and it expresses everything I was already writing. Anything that "looks like an assignment", but isn't, is subjectively a really bad idea. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
We may be able to have both: convenient default imports and convenient
non-default imports, if we bring back `export =` (which, IIRC, has been
proposed a while ago) and introduce `import =` as an analog. Example:
module "jquery" {
export = {
...
};
}
import $ = "jquery";
Not completely happy with it (as both look like assignments), but it
complements the non-default case nicely and everything combined may be the best
we can do overall.
Remaining changes – wiki:
import { encrypt, decrypt } from "crypto"; // binding a module's exports to
variables
import { encrypt as enc } from "crypto"; // binding and renaming one of a
module's exports
export { foo, bar } from "crypto"; // re-exporting specified
exports from another module
Brace-free:
import encrypt, decrypt from "crypto"; // binding a module's exports to
variables
import encrypt as enc from "crypto"; // binding and renaming one of a
module's exports
export foo, bar from "crypto"; // re-exporting specified exports
from another module
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
I was corresponding with Axel about what's possible without ambiguity,
and he pushed for brace elimination noting that 'default' is a reserved
word. This led to me remembering the export = ... form, more concise
than export default ... -- not that "more concise" must win, but it
seems worth a brief discussion. The export = form also looks more like
today's module.exports = ... from NPM/AMD.
/be
Axel Rauschmayer wrote:
We may be able to have both: convenient default imports and convenient
non-default imports, if we bring back `export =` (which, IIRC, has
been proposed a while ago) and introduce `import =` as an analog. Example:
module "jquery" {
export = {
...
};
}
import $ = "jquery";
Not completely happy with it (as both look like assignments), but it
complements the non-default case nicely and everything combined may be
the best we can do overall.
Remaining changes – wiki:
import { encrypt, decrypt} from"crypto";// binding a module's exports
to variables
import { encryptas enc} from"crypto";// binding and renaming one of a
module's exports
export { foo, bar} from"crypto";// re-exporting specified exports from
another module
Brace-free:
import encrypt, decrypt from"crypto";// binding a module's exports to
variables
import encryptas enc from"crypto";// binding and renaming one of a
module's exports
export foo, bar from"crypto";// re-exporting specified exports from
another module
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Module syntax
I really dislike `export =`. It looks like it should be creating a global variable named `export`. `export default` is perfect IMO. It also conceptually fits better with how default exports work. (I.e., they're *default* exports, they're not the entirety of the exports. They don't overwrite the module instance object, in the fashion that `module.exports =` does.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Jun 3, 2013, at 20:41 , Rick Waldron wrote:
> On Mon, Jun 3, 2013 at 2:40 PM, Axel Rauschmayer wrote:
>> On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote:
>> Bikeshedding: I generally like the module syntax, but I’d always omit the
>> braces and use `import default` for importing the default export of a module.
>>
>> From the wiki:
>>
>> module "foo" {
>> export default function() { console.log("hello!") }
>> }
>> ...
>> import default;
>>
>> What would be the bound name? foo? Am I missing something?
>
> I’d use:
> import default foo from "foo";
>
> How is this better then the existing:
>
> import foo from "foo";
>
> For importing a default export?
It’s worse. The point would be to make non-default imports simpler and lose the
braces (which make less sense with the new non-literal syntax) in those cases.
That is: it makes default imports less convenient in order to make non-default
imports more convenient and less grawlixy.
Compare – wiki:
import $ from "jquery";// import the default export of
a module
module crypto from "crypto"; // binding an external module to
a variable
import { encrypt, decrypt } from "crypto"; // binding a module's exports to
variables
import { encrypt as enc } from "crypto"; // binding and renaming one of a
module's exports
export * from "crypto";// re-exporting another module's
exports
export { foo, bar } from "crypto"; // re-exporting specified
exports from another module
Brace-free:
import default $ from "jquery";// import the default
export of a module
module crypto from "crypto"; // binding an external module to
a variable
import encrypt, decrypt from "crypto"; // binding a module's exports to
variables
import encrypt as enc from "crypto"; // binding and renaming one of a
module's exports
export * from "crypto";// re-exporting another module's
exports
export foo, bar from "crypto"; // re-exporting specified exports
from another module
Syntactic ambiguities may be a problem, though...
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote:
> Bikeshedding: I generally like the module syntax, but I’d always omit the
> braces and use `import default` for importing the default export of a
> module.
>
>From the wiki:
module "foo" {
export default function() { console.log("hello!") }
}
...
import default;
What would be the bound name? foo? Am I missing something?
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
On Mon, Jun 3, 2013 at 2:40 PM, Axel Rauschmayer wrote:
> On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote:
>
>> Bikeshedding: I generally like the module syntax, but I’d always omit the
>> braces and use `import default` for importing the default export of a
>> module.
>>
>
> From the wiki:
>
> module "foo" {
> export default function() { console.log("hello!") }
> }
> ...
> import default;
>
> What would be the bound name? foo? Am I missing something?
>
>
> I’d use:
> import default foo from "foo";
>
How is this better then the existing:
import foo from "foo";
For importing a default export?
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module syntax
> On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote:
> Bikeshedding: I generally like the module syntax, but I’d always omit the
> braces and use `import default` for importing the default export of a module.
>
> From the wiki:
>
> module "foo" {
> export default function() { console.log("hello!") }
> }
> ...
> import default;
>
> What would be the bound name? foo? Am I missing something?
I’d use:
import default foo from "foo";
Thus, the examples in the wiki [1] become:
import default $ from "jquery";// import the default export
of a module
module crypto from "crypto"; // binding an external module to a
variable
import encrypt, decrypt from "crypto"; // binding a module's exports to
variables
import encrypt as enc from "crypto"; // binding and renaming one of a
module's exports
export * from "crypto";// re-exporting another module's
exports
export foo, bar from "crypto"; // re-exporting specified exports from
another module
[1] http://wiki.ecmascript.org/doku.php?id=harmony:modules
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Module syntax
Bikeshedding: I generally like the module syntax, but I’d always omit the braces and use `import default` for importing the default export of a module. Rationale: – Reducing the grawlix factor. – Making non-default imports more convenient – which I assume will happen more often(?) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Import Module Syntax Bikeshed
Apologies if the "import module" syntax has already been agreed upon (in which case I'll be happy to use whatever it is), but in converting over some code to ES6 modules, I've found myself dissatisfied with both "variant A" and "variant B". I've created a gist to illustrate my thoughts, along with a third possibility. https://gist.github.com/3637556 Comments and harangues welcome. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
