I like the fact that this doesn't look like destructuring, since variable
binding is different from destructuring assignment. Could
```
import foo, baz from bar as bar;
```
allowed simultanous import of named exports and the module itself? If so,
the grammar gains a pleasing regularity.
To me, though, that goes back to the destructuring/not destructuring
aspect. Maybe this has floated by during the bikeshedding, but why not
something like:
//import a single named export
import foo from bar;
//import multiple named exports
import foo, baz from bar;
Thanks Kevin.
Back to bikeshedding import export syntax.
The refactoring hazards of defaulting to an object with all the exports are
going to depend on how the feature is described, talking in terms of
looking first for a default export and then returning the module body and
now you get
But if modules were said to have a default default export that was an
object with all the exports that could be overridden then that's different.
I see where you're coming from, and honestly I don't have a better argument
against a default default. (I actually tried to argue for that once
The
import 'foo'
let foo = this.get('foo')
Is less of a hassle if you only need it for when you have default and named
exports and need the module object.
On Jun 25, 2014 7:48 AM, Kevin Smith zenpars...@gmail.com wrote:
But if modules were said to have a default default export that
import 'foo'
let foo = this.get('foo')
Please no. Just...no.
: )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
import 'foo'
let foo = this.get('foo')
To be less flippant, this isn't a solution to the problem: how do I
statically bind to a module instance object? It's a runtime workaround.
Default-default aside, what's the payoff in trying to obscure the fact that
a module is always a named
import 'foo'
let foo = this.get('foo')
that was what came out of the last meeting to replace module/from semantics
the payoff is decoupling how something is imported from how something is
exported. A module is a bag of names, but there is no reason an import has
to be as well.
On
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Calvin Metcalf
calvin.metc...@gmail.com
the payoff is decoupling how something is imported from how something is
exported.
+1. Although I am uneasy about the default-default export idea, since it has
[several edge cases][1] that
the payoff is decoupling how something is imported from how something is
exported.
Maybe I'm being dense, but I must admit I find this statement to be
completely baffling. The import side always has to match the export side -
how could it possibly be any different? What am I missing here?
On Wed, Jun 25, 2014 at 1:38 PM, Kevin Smith zenpars...@gmail.com wrote:
the payoff is decoupling how something is imported from how something is
exported.
Maybe I'm being dense, but I must admit I find this statement to be
completely baffling. The import side always has to match the
One import syntax. C'mon, we've been over this for *months* Kevin.
I get that, I really do. But specifically, that would mean a
default-default, right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
default-default is the least worst one I have heard that doesn't totally
change everything,
On Wed, Jun 25, 2014 at 2:08 PM, Kevin Smith zenpars...@gmail.com wrote:
One import syntax. C'mon, we've been over this for *months* Kevin.
I get that, I really do. But specifically, that would
default-default is the least worst one I have heard that doesn't totally
change everything,
Fair enough. Thanks for putting up with my questioning - I think I have a
better understanding of where you and Scott are coming from now.
Correct me if I'm wrong, but the perspective says: why would
On Wed, Jun 25, 2014 at 2:59 PM, Kevin Smith zenpars...@gmail.com wrote:
Correct me if I'm wrong, but the perspective says: why would I need to
import the multiple-exports if I'm specifically overriding the exports with
a default? Having a way to import both the default and multiple-exports
// I have a module named `foo`.
// I don't care what `foo` is.
// Including whether or not its a namespace.
// I need make no promises about identifier `foo`.
import {bar} from './foo';
On Wed, Jun 25, 2014 at 12:52 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Jun 25, 2014 at 2:59
@John Barton: Yes, ideally that syntax would work as well when you don't
need a namespace. But sometimes you do need a namespace, even if you don't
care precisely what it is:
```
import {format} from 'url';
import {format} from 'util';
import {connect} from 'tls';
import {connect} from 'net';
You don’t actually need a namespace for this, though it may be more
convenient/aesthetically pleasing than the alternative:
```
import {format as formatURL} from 'url';
import {format} from 'util';
import {connect as tlsConnect} from 'tls';
import {connect as netConnect} from 'net';
import {fork
On Wed, Jun 25, 2014 at 6:17 PM, Brian Donovan m...@brian-donovan.com wrote:
You don’t actually need a namespace for this, though it may be more
convenient/aesthetically pleasing than the alternative:
may? (!)
--scott
___
es-discuss mailing list
Ron Buckton's suggestion above makes the most sense to me personally. And I
saw many people arrive to a very similar idea a few times in these recent
module threads - but it kind of always gets rejected with no substantial
reasoning.
Please don't dismiss his suggestion super quickly with es6
Ron Buckton's suggestion above makes the most sense to me personally. And
I saw many people arrive to a very similar idea a few times in these recent
module threads - but it kind of always gets rejected with no substantial
reasoning.
I'm not really sure what Ron's proposal is, but I'm going
On Tue, Jun 24, 2014 at 9:26 AM, Kevin Smith zenpars...@gmail.com wrote:
Ron Buckton's suggestion above makes the most sense to me personally. And
I saw many people arrive to a very similar idea a few times in these
recent
module threads - but it kind of always gets rejected with no substantial
The reason why that's problematic is that it makes adding a default export
at a later date a breaking change for consumers of the module. You would
essentially have to decide whether your module is going to have a default
export (other than the module instance object of course) when you
The reason why that's problematic is that it makes adding a default
export at a later date a breaking change for consumers of the module. You
would essentially have to decide whether your module is going to have a
default export (other than the module instance object of course) when you
Lots of things are breaking API changes. Changing the name of one of the
named exports, for instance. Critically, in Ron's proposal, you *can*
change a default export to named exports later (or vice versa) *without
changing the users of the module*.
Maybe, but certianly not without
On Tue, Jun 24, 2014 at 10:05 AM, Kevin Smith zenpars...@gmail.com wrote:
Lots of things are breaking API changes. Changing the name of one of the
named exports, for instance. Critically, in Ron's proposal, you *can*
change a default export to named exports later (or vice versa) *without
I don't agree that the changes to the semantics are large, if we're
talking about simply allowing a single syntactic form for both named and
default import and Ron's option (A) (where default and named exports can
not co-exist... until ES7 at least).
But unless you want to rewrite the
Side note: is that legal? I assumed you wouldn't be able to do that due to
default being a reserved word.
On Jun 24, 2014 7:53 PM, Kevin Smith zenpars...@gmail.com wrote:
I don't agree that the changes to the semantics are large, if we're
talking about simply allowing a single syntactic form
...@gmail.com
Cc: EcmaScriptmailto:es-discuss@mozilla.org
Subject: Re: ModuleImport
Side note: is that legal? I assumed you wouldn't be able to do that due to
default being a reserved word.
On Jun 24, 2014 7:53 PM, Kevin Smith
zenpars...@gmail.commailto:zenpars...@gmail.com wrote:
I don't
Side note: is that legal? I assumed you wouldn't be able to do that due
to default being a reserved word.
Definitely. Exports can be named any IdentifierName, so all of this is
valid:
export { foo as class, bar as switch, baz as default };
And you can import IdentifierNames as well:
If it is considered legal, then I'd say maybe the default export should
be named @@default (or a similar symbol) instead.
That was proposed at one time, but then the whole default business (which
is arguably a bit dodgy to begin with) becomes something more than just
sugar. A user cannot
ES6 favors the single/default export style, and gives the sweetest syntax
to importing the default. Importing named exports can and even should be
slightly less concise.
It seems like ES6 favors single import (`import singleThing from module`)
but prefers multiple export (`export var a = 5;`),
Reading Marius' email, I realised what I find confusing in the newly
proposed syntax that uses `*' to import the default export.
The `*' symbol universally represents a glob of everything, but when
used to import from a module that has multiple exports, you won't get
everything, you will get
On Jun 20, 2014, at 11:36 , Sébastien Cevey seb.ce...@guardian.co.uk wrote:
Reading Marius' email, I realised what I find confusing in the newly
proposed syntax that uses `*' to import the default export.
The `*' symbol universally represents a glob of everything, but when
used to import
On 20 June 2014 11:39, Axel Rauschmayer a...@rauschma.de wrote:
The `*' symbol universally represents a glob of everything, but when
used to import from a module that has multiple exports, you won't get
everything, you will get either the single default export (if there is
one) or nothing.
On Thu, Jun 19, 2014 at 8:48 PM, Brendan Eich bren...@mozilla.org wrote:
Domenic Denicola wrote:
The transitional era will be a particularly vulnerable time for TC39's
module design, however: as long as people are using transpilers, there's an
opportunity for a particularly well-crafted,
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Sébastien Cevey
Sent: Friday, June 20, 2014 3:46 AM
To: Axel Rauschmayer
Cc: es-discuss list
Subject: Re: ModuleImport
On 20 June 2014 11:39, Axel Rauschmayer a...@rauschma.de wrote
Cevey
Sent: Friday, June 20, 2014 3:46 AM
To: Axel Rauschmayer
Cc: es-discuss list
Subject: Re: ModuleImport
On 20 June 2014 11:39, Axel Rauschmayer a...@rauschma.de wrote:
The `*' symbol universally represents a glob of everything, but
when used to import from a module
From: John Barton [mailto:johnjbar...@google.com]
Sent: Friday, June 20, 2014 3:48 PM
ES6 already has what you want:
_Named Exports_:
export var foo = 1;
_Single Export Object_:
export var moduleName = {
foo: 1,
bar: function() {}
};
_Single Export Function_:
export
On Fri, Jun 20, 2014 at 4:17 PM, Ron Buckton rbuck...@chronicles.org
wrote:
From: John Barton [mailto:johnjbar...@google.com]
Sent: Friday, June 20, 2014 3:48 PM
ES6 already has what you want:
_Named Exports_:
export var foo = 1;
_Single Export Object_:
export var
That’s a good solution. Logically, `import { * } from fs` may make more
sense, but I prefer the “unbraced” asterisk, because it results in less clutter.
Does the proposed syntax clash with `export * FromClause` (which, I’m assuming,
re-exports everything, not just the named exports)?
I’d
On Jun 19, 2014, at 2:03 AM, Axel Rauschmayer a...@rauschma.de wrote:
Does the proposed syntax clash with `export * FromClause` (which, I’m
assuming, re-exports everything, not just the named exports)?
No inconsistency; it imports everything. Exactly the same semantics as always,
just a
Thanks, Dave, for bringing that up, it shows you're open for feedback. That
said (bikeshed begins), what's wrong with:
```js
import fs as fs;
```
? I feel that a lot of effort went in ES6 into reducing boilerplate via
e.g. arrow functions, classes etc. but if you start with Node's require,
this
This is a key sentence in David’s proposal: “ES6 favors the single/default
export style, and gives the sweetest syntax to importing the default. Importing
named exports can and even should be slightly less concise.”
On Jun 19, 2014, at 12:31 , Michał Gołębiowski m.go...@gmail.com wrote:
One other option could be for import name from 'path' to resolve to the
module body there is no default export, thanks to the static analysis
you'll always know when default is present.
The import 'path'/this.get syntax is a lot less burdensome if it's only
required by edge cases like needing
On Thu, Jun 19, 2014 at 12:40 PM, Axel Rauschmayer a...@rauschma.de wrote:
This is a key sentence in David’s proposal: “ES6 favors the single/default
export style, and gives the sweetest syntax to importing the default.
Importing named exports can and even should be slightly less concise.”
What is the behavior if a module doesn't define a default export and the syntax
for importing the default export is used?
What is the behavior if a module only defines a default export and the syntax
for importing named imports is used?
---
R. Mark Volkmann
Object Computing, Inc.
On Jun 19,
```js
import * as fs from fs; // importing the named exports as an object
import Dict from dict; // importing a default export, same as ever
```
It's a little wordy, but it fulfills the goals and feels pleasant to write.
+1 from me.
___
On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
One other option could be for import name from 'path' to resolve to the
module body there is no default export, thanks to the static analysis
you'll always know when default is present.
That is a refactoring
On Jun 19, 2014, at 3:31 AM, Michał Gołębiowski m.go...@gmail.com wrote:
Thanks, Dave, for bringing that up, it shows you're open for feedback. That
said (bikeshed begins),
lol :)
what's wrong with:
```js
import fs as fs;
```
Indeed we've talked about that one before. Some objected to
With this idea you cannot look at the import statement to see if the
imported binding is a module instance object or not.
the flip side of that is that you don't need to know whether something is a
default export or a named export to import it e.g.
```js
export let foo = function () {}
export
Sorry to be dense, but I would appreciate more elaboration of this sentence:
On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer a...@rauschma.de wrote:
This is a key sentence in David’s proposal: “ES6 favors the single/default
export style,
What is the single/default export style? If I
On Thursday, June 19, 2014 5:17 AM, David Herman dher...@mozilla.com wrote:
```js
import * as fs from fs; // importing the named exports as an object
import Dict from dict; // importing a default export, same as ever
```
My first reaction is to think that a lot of developers will ask: why
On Thu, Jun 19, 2014 at 1:15 AM, David Herman dher...@mozilla.com wrote:
## Proposal
OK, so we're talking about a better syntax for importing a module and binding
its named exports to a variable (as distinct from importing a module and
binding its default export to a variable). Here's my
On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
One other option could be for import name from 'path' to resolve to the
module body there is no default export, thanks to the static analysis
you'll always know when default is present.
That is a refactoring
On Thu, Jun 19, 2014 at 7:13 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
With this idea you cannot look at the import statement to see if the
imported binding is a module instance object or not.
the flip side of that is that you don't need to know whether something is
a default
On Thu, Jun 19, 2014 at 6:57 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
One other option could be for import name from 'path' to resolve to the
module body there is no default export, thanks to the
On Jun 19, 2014, at 16:17 , John Barton johnjbar...@google.com wrote:
Sorry to be dense, but I would appreciate more elaboration of this sentence:
On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer a...@rauschma.de wrote:
This is a key sentence in David’s proposal: “ES6 favors the
What if the `import module/id;` form was an expression that evaluated to
the module instance object.
This means everything stays as it is now except we remove the ModuleImport
form and if you want to use the module instance object you can do: `var foo
= import foo;`. You could also do `var { bar
On Thu, Jun 19, 2014 at 1:23 PM, Chris Toshok tos...@gmail.com wrote:
On Thu, Jun 19, 2014 at 6:57 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
One other option could be for import name from 'path' to
On Thu, Jun 19, 2014 at 10:53 AM, Matthew Robb matthewwr...@gmail.com
wrote:
What if the `import module/id;` form was an expression that evaluated to
the module instance object.
This means everything stays as it is now except we remove the ModuleImport
form and if you want to use the module
On Thu, Jun 19, 2014 at 11:06 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
On Thu, Jun 19, 2014 at 1:23 PM, Chris Toshok tos...@gmail.com wrote:
On Thu, Jun 19, 2014 at 6:57 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf
On Thu, Jun 19, 2014 at 2:29 PM, Chris Toshok tos...@gmail.com wrote:
Calvin's suggestion would allow the following refactoring to be done by
the module author without impacting his users, something not possible with
current ES6:
```js
// a.js V1
export default { C: class C { ... } }
On Jun 19, 2014, at 13:36 , Michał Gołębiowski m.go...@gmail.com wrote:
On Thu, Jun 19, 2014 at 12:40 PM, Axel Rauschmayer a...@rauschma.de wrote:
This is a key sentence in David’s proposal: “ES6 favors the single/default
export style, and gives the sweetest syntax to importing the default.
On Thu, Jun 19, 2014 at 10:48 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Jun 19, 2014, at 16:17 , John Barton johnjbar...@google.com wrote:
Sorry to be dense, but I would appreciate more elaboration of this
sentence:
On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer a...@rauschma.de
From: es-discuss es-discuss-boun...@mozilla.org on behalf of David Herman
dher...@mozilla.com
* **Without ModuleImport, authors of multi-export modules would be pressured
to circumvent the named exports functionality.**
I am glad this point was recognized and acted upon. I feel listened-to
To me this is a bug not a feature; we should keep it simple and just have one
way to get one import from one export.
Just to make a connection to the topic, Dave's intro says:
We've consistently seen confusion between the semantics of ModuleImport
and default export.
For me this
From: es-discuss es-discuss-boun...@mozilla.org on behalf of James Burke
jrbu...@gmail.com
1) Only allow export default or named exports, not both.
As a modification of the current design, this hurts use cases like
```js
import glob, { sync as syncGlob } from glob;
import _, { zip } from
All good points. I don’t see “TC39 versus the community”, though, I’m seeing
many factions with different opinions.
On Jun 19, 2014, at 21:13 , Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of James Burke
jrbu...@gmail.com
Yes, but I was not clear: where is the evidence that ES6 favors this form
or single named export. My experience is opposite: the simple thing in ES6
is to export those things you want exported. If it's one thing, then one;
if it's 6 things then 6. One is not favored.
FWIW, my experience
On Thu, Jun 19, 2014 at 12:13 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of James Burke
jrbu...@gmail.com
1) Only allow export default or named exports, not both.
As a modification of the current design, this hurts use
From: James Burke [mailto:jrbu...@gmail.com]
The argument for allowing both a default and named exports seems ill-defined
based on data points known so far
I mean, it seems based on the idea that named exports are super-important, and
that packages like glob and underscore should use them.
But why? The benefit of named exports in general is that you get the magic
mutable bindings -- but underscore and glob are mature libraries without
circular dependencies on other code. They would gain exactly nothing from
switching to named exports.
--scott
On Jun 19, 2014 4:16 PM, Domenic
Domenic Denicola wrote:
This is part of a larger issue regarding the messaging of TC39 and versioned
ECMAScript, which is somewhat out of touch with
[reality](https://twitter.com/annevk/status/479334108150374401).
(Spinach.)
I hope we can discuss this at the next TC39 meeting. But I
Domenic Denicola wrote:
The transitional era will be a particularly vulnerable time for TC39's module
design, however: as long as people are using transpilers, there's an
opportunity for a particularly well-crafted, documented, and supported
transpiler to give alternate semantics grounded in
101 - 175 of 175 matches
Mail list logo
