On Thu 19 Jun 2014 18:02, Mark S. Miller erig...@google.com writes:
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
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;`),
Hi,
Is there plans to add a range generator to the standard library ?
It would be especially useful with array comprehension, when initializing
arrays :
this._year = [ new Month(n) for n of Number.range(0, 12) ]
--
Maël Nison (arcanis https://twitter.com/arcanis)
Frontend Developer @
Hi,
I'm not quite sure what this is all about, so forking in hope for
clarifications.
I'm sorry to send a message that will probably be read as noise by a lot
of people, but I'm also tired of some of these pointless and
unconstructive, if not destructive, fights among people (in here, on
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.
Btw, I used the wrong syntax in my precedent mail. It should be :
[ for (n of Number.range(0, 12)) new Month(n) ]
On 20 June 2014 11:24, Maël Nison nison.m...@gmail.com wrote:
Hi,
Is there plans to add a range generator to the standard library ?
It would be especially useful with
Yes, good catch. This is a change, and it is now allowed.
On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo wi...@igalia.com wrote:
On Thu 19 Jun 2014 18:02, Mark S. Miller erig...@google.com writes:
Yes. For both strict and sloppy, for both static/literal and
dynamic/computed, duplicate
Can you develop these particular accusations?
Why would TC39 have priorities that don't align with the needs of developers?
especially on modules which are clearly one of the most awaited feature as
far as developers are concerned?
TC39 has a lot of constituents who use their experience
On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Can you develop these particular accusations?
Why would TC39 have priorities that don't align with the needs of
developers? especially on modules which are clearly one of the most awaited
feature as far as
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,
I'll make this point as concisely as possible, since this conversation is
quite given to noise:
While others may disagree, I feel the source of contention/disunity on
modules is more fundamental than syntax or who's (not) listening to who.
Specifically, ES6 modules are far less immune to
On Jun 20, 2014 11:39 AM, John Barton johnjbar...@google.com wrote:
I started out with a similar opinion. Then I wrote some ES6 code.
What we need now is experience from using ES6-modules. We have plenty
of decent implementations. We've built nodejs and browser applications
based on ES6
On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@google.com
wrote:
I started out with a similar opinion. Then I wrote some ES6 code.
What we need now is experience from using ES6-modules. We have plenty of
decent implementations. We've built nodejs and browser applications based
on
A minimal, pragmatic and well integrated solution is the ES6 Module Transpiler:
https://github.com/square/es6-module-transpiler
Additionally, Addy Osmani maintains a comprehensive list of tools:
https://github.com/addyosmani/es6-tools
Axel
On Jun 20, 2014, at 19:54 , Jasper St. Pierre
I am trying to stay outside this discussion as much as I can but there is a
specific sentence that I'd like to understand:
On Fri, Jun 20, 2014 at 8:39 AM, John Barton johnjbar...@google.com wrote:
The ES5-module using community tried, valiantly, to reach a compromise
module solution. They
On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am trying to stay outside this discussion as much as I can but there is
a specific sentence that I'd like to understand:
On Fri, Jun 20, 2014 at 8:39 AM, John Barton johnjbar...@google.com
wrote:
The
I think tools made `require` the winning choice but about having both I am
not sure I've read about dynamic folder such:
`import _ from loDashFolder`
if that's a thing then
```
var require = function (fromWhere) {
return import _ from loDashFolder
};
```
or whatever will be
Best Regards
typo ...
```
var require = function (fromWhere) {
return import * from fromWhere
};
```
or something similar
On Fri, Jun 20, 2014 at 3:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I think tools made `require` the winning choice but about having both I am
not sure I've
-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:
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 function fName() { }
And even cooler, the syntax for import is uniform,
import {foo} from
On Friday, June 20, 2014 7:15 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
typo ...
```
var require = function (fromWhere) {
return import * from fromWhere
};
```
That's not valid ES6. It's specified that:
- Import and export statements can only be top level statements
-
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
25 matches
Mail list logo
