Thanks to everyone for working through the issues around ModuleImport. I know
it's been frustrating, but the discussions have really helped clarify the key
constraints.
## Constraints
First, let me restate the most important arguments. In favor of removal:
* **The syntactic distinction
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
On Thu, Jun 19, 2014 at 1:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 18, 2014, at 4:12 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The spec. current says throw for this Symbol.prototype case. The
(reasonable) opposing view is that toString should never throw.
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,
On Wed, Jun 18, 2014 at 5:29 PM, Kevin Smith zenpars...@gmail.com wrote:
I think Allen's suggestion of providing constructor arguments to @@create
is promising. That would allow the implementation to allocate and
initialize an object in one go, if desired. That seems to embody the
advantages
I'd like to understand. Why doesn't it work?
Allen wondered the same, so I'll just paste my reply to him:
So I was a little embarrassed about not thinking it through, and wanted to
just void the comment.
But specifically, if the subclass wants to have a different set of
constructor
On Wed, Jun 18, 2014 at 4:09 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Jason covered the combinations: his proposal supports class subclassing
function, etc. What concretely do you mean here, if not that? If you mean
refactoring from one to the other, what observably differs?
My
On Wed, Jun 18, 2014 at 4:09 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
function F(x) { /* ??? the initial message really isn't explicit about what
does here */ };
I think focusing on what was in the initial message vs. what was
explained later (or remains open for discussion) does us
```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.
___
The most important thing here (I agree with Andreas R.) is -- if
possible -- avoiding uninitialized object observability.
I agree that uninitialized observability is a pain and has been a
on-going source
of reentrancy bugs in the the more complex built-in constructors. I
want to
explore
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 Wed, Jun 18, 2014 at 12:07 AM, Brendan Eich bren...@mozilla.org wrote:
Domenic Denicola wrote:
Another way of guiding the decision: I don't quite recall where the spec
landed `{ x: 1, [x]: 2 }`, but we should probably be consistent with that.
*Mark Miller:* I am ok with removing the
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
Yes. For both strict and sloppy, for both static/literal and
dynamic/computed, duplicate property names/symbols in object literals are
no longer an error. Instead, in left-to-right order, each cause the
equivalent of a [[DefineOwnProperty]] on the new object, so that rightward
definitions silently
Regarding Domenic's question:
Domenic Denicola wrote:
Another way of guiding the decision: I don't quite recall where the
spec landed `{ x: 1, [x]: 2 }`, but we should probably be consistent with
that.
The initial value of the x property would be 2. It should not be observable
that it was
Can i bring back the good old JScript unknown? :P
Sent from my Windows Phone From: Brendan Eich
Sent: 6/18/2014 17:15
To: Allen Wirfs-Brock
Cc: Mark S. Miller; Mark Miller; Erik Arvidsson; Jason Orendorff;
es-discuss@mozilla.org list
Subject: Re: Standard builtins' prototypes and toString
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 3:18 AM, Till Schneidereit wrote:
On Thu, Jun 19, 2014 at 1:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 18, 2014, at 4:12 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The spec. current says throw for this Symbol.prototype case. The
While we're on the topic, shall we discuss `valueOf()`? Should it get the
same treatment?
--scott
On Jun 19, 2014 1:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jun 19, 2014, at 3:18 AM, Till Schneidereit wrote:
On Thu, Jun 19, 2014 at 1:39 AM, Allen Wirfs-Brock
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 7:46 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
While we're on the topic, shall we discuss `valueOf()`? Should it get the
same treatment?
--scott
Oh, yes: I always considered the `toString` discussion to really be about
`valueOf`, too.
On Jun 19, 2014
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
Kevin Smith wrote:
The current design does posit uninitialized objects, which
implementers are obviously uncomfortable with. Could it be that we
just haven't yet developed the implementation techniques for dealing
with such uninitialized objects? Or is there a real problem with being
able to
On Jun 19, 2014, at 10:46 AM, C. Scott Ananian wrote:
While we're on the topic, shall we discuss `valueOf()`? Should it get the
same treatment?
--scott
I don't think so. To me, toString is a special case because it is explicitly
applied so often, particularly for debugging purposes.
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 { ... } }
From a security perspective as well, I have always been uncomfortable with
observable uninitialized objects, though I have been too lazy to try
demonstrating a concrete attack.
On Jun 19, 2014 11:12 AM, Brendan Eich bren...@mozilla.org wrote:
Kevin Smith wrote:
The current design does posit
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
On Thu, Jun 19, 2014 at 8:16 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 19, 2014, at 10:46 AM, C. Scott Ananian wrote:
While we're on the topic, shall we discuss `valueOf()`? Should it get the
same treatment?
--scott
I don't think so. To me, toString is a special case
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
On Thu, Jun 19, 2014 at 8:39 AM, André Bargull andre.barg...@udo.edu wrote:
That means depending on the class/built-in a subclass needs to override
either the @@create method or the constructor function or both?
For example let's take the Map built-in. The @@create method will initialise
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
54 matches
Mail list logo
