On 10 December 2012 05:30, Kevin Smith khs4...@gmail.com wrote:
OK, then suppose we have these two separate forms:
import x from url; // Bind x to the anonymous export, if defined,
otherwise error
and
import module x from url; // Bind x to the module instance
In the vast majority
I consider such second-guessing of user intention, which can lead one
construct to mean completely different things, harmful. It makes code
less readable and more brittle. And again, it's a semantic hack,
making the language more complex. I just don't see why it would be
worth it, especially
On 9 December 2012 02:10, Kevin Smith khs4...@gmail.com wrote:
So if you didn't set the anonymous binding in some module x.js, what would
this do:
import x from x.js;
Would x be bound to the module instance or would we get a binding error?
Since it is just sugar, and supposed to be
On 9 December 2012 03:51, Domenic Denicola dome...@domenicdenicola.com wrote:
From: Andreas Rossberg [mailto:rossb...@google.com]
On 6 December 2012 16:44, Domenic Denicola
dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you were to allow arbitrary expressions and patterns,
then this would imply aliasing of arbitrary object properties. Not
only is this a
I see my previous email did not format well in the archive. I'm retrying this.
(Could someone please give me some formatting tips?)
Nathan
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you
On 9 December 2012 15:04, Nathan Wall nathan.w...@live.com wrote:
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you were to allow arbitrary expressions and patterns,
then this would imply
Yeah, that makes sense. I agree. Thanks.
Nathan
On 9 December 2012 15:04, Nathan Wall nathan.w...@live.com wrote:
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you were to allow
Domenic Denicola wrote:
-Original Message-
From: Andreas Rossberg [mailto:rossb...@google.com]
Sent: Thursday, December 6, 2012 11:31
On 6 December 2012 16:44, Domenic Denicola
dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
Since it is just sugar, and supposed to be equivalent to the
expansion, you (fortunately) would get an error (statically).
OK, then suppose we have these two separate forms:
import x from url; // Bind x to the anonymous export, if defined,
otherwise error
and
import module x from
So if you didn't set the anonymous binding in some module x.js, what
would this do:
import x from x.js;
Would x be bound to the module instance or would we get a binding error?
For module naming, we'd need to have a different syntax. In earlier
versions of the proposal that was
module
-Original Message-
From: Andreas Rossberg [mailto:rossb...@google.com]
Sent: Thursday, December 6, 2012 11:31
On 6 December 2012 16:44, Domenic Denicola
dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
On 6 December 2012 17:54, Kevin Smith khs4...@gmail.com wrote:
Note, however, that you still assume some hack in the semantics with
the if it exists part. To avoid that, you need to divorce the import
syntax from the naming-an-external-module syntax -- which I'd actually
prefer anyway, and
On Thu, Dec 6, 2012 at 1:46 PM, Brendan Eich bren...@mozilla.org wrote:
David Herman wrote:
Cool, definitely want the plain identifier form, it's part of the
binding (and destructuring) pattern language.
Well, the thing is it isn't consistent with the destructuring meaning:
dropping the
Feel free to suggest alternatives, but forgive me if I'm not willing to
respond to every opinion on this one. :}
How about:
import ga as ga;
to import the whole module, and
import ga as { foo, bar };
to import just parts of the module. I feel like this makes a lot of sense, and
On Dec 5, 2012, at 11:52 PM, Brendan Eich bren...@mozilla.org wrote:
ExportDeclaration: export { ExportSpecifier (, ExportSpecifier)*
} ;
ExportDeclaration: export Identifier (, Identifier)* ;
ExportDeclaration: export * from StringLiteral ;
Reasonable point, I'll think about
On Thu, Dec 6, 2012 at 8:25 AM, David Herman dher...@mozilla.com wrote:
On Dec 5, 2012, at 7:16 PM, Kevin Smith khs4...@gmail.com wrote:
1) export ExportSpecifierSet (, ExportSpecifierSet)* ;
This rule seems too permissive. It allows strange combinations like:
export x, { y:
Well, the thing is it isn't consistent with the destructuring meaning: dropping the curlies here
means extracting a single export (aka property), which is not what it means in destructuring
assignment/binding anywhere else.
But that said, the convenience may well still trump the inconsistency.
On Thu, Dec 6, 2012 at 1:25 AM, David Herman dher...@mozilla.com wrote:
On Dec 5, 2012, at 7:16 PM, Kevin Smith khs4...@gmail.com wrote:
2) Do we need `export *;`?
I don't see the point of exporting every declaration in the current module
scope. If the programmer wants to export a bunch of
Summaries with comments:
1) export ExportSpecifierSet (, ExportSpecifierSet)* ;
Brendan pointed out that other binding forms allow lists (including the
import form), so why not this one? I actually didn't realize that lists
are allowed with import:
ImportDeclaration ::= import
On Thu, Dec 6, 2012 at 9:42 AM, Kevin Smith khs4...@gmail.com wrote:
Dave responded by pointing out that we don't want from to have
overloaded semantics. I actually think this form has potential, because it
further aligns import with the other binding forms:
var a = x;
var { b } =
+1
Compared to Node.js, I love ES6 exports, but Node.js module imports are easier
to understand.
Claus’ suggestion would make `import` similar to `let` and people could
basically think of modules as objects.
On Dec 6, 2012, at 10:41 , Claus Reinke claus.rei...@talk21.com wrote:
Well, the
-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Erik Arvidsson [erik.arvids...@gmail.com]
Sent: Thursday, December 06, 2012 09:54
To: Kevin Smith
Cc: es-discuss
Subject: Re: Module Comments
On Thu, Dec 6, 2012 at 9:42 AM, Kevin Smith
khs4...@gmail.commailto:khs4
On 6 December 2012 15:42, Kevin Smith khs4...@gmail.com wrote:
5) Dynamic exports via `export = ?` could make interop with existing
module systems easier. But how does that work?
Dave gave an outline. I'm liking this. What are the downsides, if any?
The downside is that it introduces a
import.
--
*From:* es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org]
on behalf of Erik Arvidsson [erik.arvids...@gmail.com]
*Sent:* Thursday, December 06, 2012 09:54
*To:* Kevin Smith
*Cc:* es-discuss
*Subject:* Re: Module Comments
On Thu, Dec 6
On 6 December 2012 16:44, Domenic Denicola dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
https://gist.github.com/1ab3f0daa7b37859ce43
I would *really* appreciate if people read it (it's easy reading, I
promise!) and incorporated some of our
The downside is that it introduces a severe anomaly into the module
semantics (a module which actually has no instance). I could live with
this feature if we were to find a way to explain it in terms of simple
syntactic sugar on both the import and export side, but screwing and
complicating
On 6 December 2012 17:33, Kevin Smith khs4...@gmail.com wrote:
The downside is that it introduces a severe anomaly into the module
semantics (a module which actually has no instance). I could live with
this feature if we were to find a way to explain it in terms of simple
syntactic sugar on
What about trying it the other way, flip everything.
import foo as bar;
import foo as { baz }
On Thu, Dec 6, 2012 at 8:42 AM, Andreas Rossberg rossb...@google.comwrote:
On 6 December 2012 17:33, Kevin Smith khs4...@gmail.com wrote:
The downside is that it introduces a severe anomaly into
On 6 December 2012 17:46, Matthew Robb matthewwr...@gmail.com wrote:
What about trying it the other way, flip everything.
import foo as bar;
import foo as { baz }
Hm, I don't understand. What would that solve?
/Andreas
___
es-discuss mailing list
Well the argument being that as it stands it's inconsistent having the
identifier on the RHS for import from and LHS in import as:
import baz from foo;
import foo as foo;
I'm just throwing out simple options for solving that inconsistency.
Possibly even thinking about them as declarations makes
Note, however, that you still assume some hack in the semantics with
the if it exists part. To avoid that, you need to divorce the import
syntax from the naming-an-external-module syntax -- which I'd actually
prefer anyway, and which was the case in the previous version of the
proposal.
Every module instance has a $DEFAULT export binding. Normally, it is
set to the module instance itself. `export = ?` overrides the value of
that binding. `import x from y` binds $DEFAULT in y to x. Maybe?
That would be how Node.js does. For those unfamiliar with how it works,
it's
David Herman wrote:
Cool, definitely want the plain identifier form, it's part of the binding
(and destructuring) pattern language.
Well, the thing is it isn't consistent with the destructuring meaning: dropping
the curlies here means extracting a single export (aka property), which is not
David Herman wrote:
On Dec 5, 2012, at 7:16 PM, Kevin Smithkhs4...@gmail.com wrote:
3) I'm just OK with as. Note that it inverts the position of the string and
the binding:
import { x } from goo;
import ga as ga;
Which makes it harder to read when you have a bunch of imports
On Dec 5, 2012, at 10:41 PM, Herby Vojčík he...@mailbox.sk wrote:
import x from goo;
Already taken. You can't use one syntax to mean two things.
import ga for ga;
That doesn't have any correspondence to its meaning in English.
import x from goo;
That's identical to your first suggestion.
David Herman wrote:
On Dec 5, 2012, at 10:41 PM, Herby Vojčíkhe...@mailbox.sk wrote:
import x from goo;
Already taken. You can't use one syntax to mean two things.
I don't. These were included to show the two syntaxes (existing from and
proposed instead-of-as grouped together; to see
I don't see why you can't treat it like this: import local accessor from
resource
import ga from ga;
If you want to import specific exports then use curlies or dot notation
import ga.foo from ga;
import { foo } from ga;
On Wed, Dec 5, 2012 at 11:05 PM, Herby Vojčík he...@mailbox.sk wrote:
On Dec 5, 2012, at 11:05 PM, Herby Vojčík he...@mailbox.sk wrote:
import x from goo;
Already taken. You can't use one syntax to mean two things.
I don't. These were included to show the two syntaxes (existing from and
proposed instead-of-as grouped together; to see how they look mixed).
On Dec 5, 2012, at 11:09 PM, Matthew Robb matthewwr...@gmail.com wrote:
I don't see why you can't treat it like this: import local accessor from
resource
import ga from ga;
We really don't want `from` to be dual-purposed to sometimes mean the whole
module itself, and sometimes extracting
David Herman wrote:
On Dec 5, 2012, at 7:16 PM, Kevin Smithkhs4...@gmail.com wrote:
1) export ExportSpecifierSet (, ExportSpecifierSet)* ;
This rule seems too permissive. It allows strange combinations like:
export x, { y: a.b.c, z }, { j, k }, * from bloop;
I think it would be
41 matches
Mail list logo
