On Tue, Jun 10, 2014 at 1:13 AM, Kevin Smith zenpars...@gmail.com wrote:
```
ImportClause :
ImportedBinding
ImportedBinding , NamedImports
NamedImports
```
Side topic, but this particular production:
ImportClause: ImportedBinding , NamedImports
needs to die an immediate
On Tue, Jun 10, 2014 at 9:06 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Marius Gundersen
This will likely lead to a lot of confusion, not only for module makers
but also for module consumers.
Agreed. Which
On Sat 07 Jun 2014 21:28, Tab Atkins Jr. jackalm...@gmail.com writes:
do you also disagree with Python's high similarity between array
comprehensions and generator comprehensions?
It seems that we have lost context on both sides, both in David's slides
and in my note ;) One of David's thoughts
Agreed. Which is why I predict module makers will, at the encouragement of
module consumers, stick to default-export only, since it is more in line
with existing practice.
FWIW, I predict the opposite, but I could be wrong. A really good thing
about the current design is that it allows
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Marius
Gundersen
I'd say we only support named exports, something like this:
https://gist.github.com/mariusGundersen/88a4c5690e08da0d07f6
If you do that, the real-world consequences will be even worse. Nobody (to a
first
If we don't have a really clean and simple upgrade path for all existing users
of module systems, I can't see ES6 modules gaining widespread adoption. If
nobody objects to that core premise, we must make it easy for users and
producers of modules like underscore, as well as producers and
These and other options have been discussed on es-discuss over the past 2
or 3 years, but didn't win out. (I'm having trouble finding links at the
moment, unfortunately.) No new information is being presented here.
Again, the current design was a hard-earned compromise and should not be
Please, cosmetic changes only! : )
Fair enough. In that spirit, how about we keep the functionality that was
recently dropped, but fix the strange wording of it (a cosmetic change) so that
it becomes:
```js
import 'underscore' as _;
```
as has been suggested by other people. It's not
These and other options have been discussed on es-discuss over the past 2
or 3 years
But back then there was no real world usage yet? Shouldn't new feedback be
taken into account?
On Tue, Jun 10, 2014 at 2:27 PM, Forbes Lindesay for...@lindesay.co.uk
wrote:
Please, cosmetic changes only!
(bikeshed: don't leave out this option for the syntax `import module from
underscore`)
On Tue, Jun 10, 2014 at 3:15 PM, Karolis Narkevičius karoli...@gmail.com
wrote:
These and other options have been discussed on es-discuss over the past
2 or 3 years
But back then there was no real world
(bikeshed: don't leave out this option for the syntax `import module from
underscore`)
Unfortunately, this one won't work because module in this context is a
plain ol' identifier. AFAIK, there's no interest in making module a
proper keyword. (Right now it's just a contextual keyword.)
These and other options have been discussed on es-discuss over the past
2 or 3 years
But back then there was no real world usage yet? Shouldn't new feedback be
taken into account?
If there is new data it should definitely be considered. I just don't see
any new data right now that changes
On Tue, Jun 10, 2014 at 5:19 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Marius Gundersen
I'd say we only support named exports, something like this:
I've been thinking about this thread a lot the last couple days. I started
out feeling defensive of the current proposal but I think I do agree that
the idea of live bound imports is neat it's also not something I'm asking
for or planning to use in the near term. I really just want single exports
Hi All
Do you know if it is planned or maybe in discussion for ES7 to have a
simple clone system on objects ?
There are different notations, from :
- jquery
Object.clone( [withDataAndEvents ] [, deepWithDataAndEvents ] )
( but only for DOM element )
- underscore
_.clone(object)
( return
Object.create() ? It's not exactly cloning, but it'll probably work better than cloning in most cases. 10.06.2014, 20:33, "Maxime Warnier" mar...@gmail.com:Hi All Do you know if it is planned or maybe in discussion for ES7 to have a simple clone system on objects ? There are different notations,
(I first tried to send this last week, but it seems the es-discuss
mailman is filtering some of my mail as spam or something?)
Hello,
I've been working with jorendorff to try to write a description of the
Loader part of the ES6 spec, to make sure I have a good grip of what the
spec says before I
And maybe there should be a Object.move for value types...
From: Frankie Bagnardi f.bagna...@gmail.commailto:f.bagna...@gmail.com
Date: Tuesday, June 10, 2014 at 2:47 PM
To: Alex Kocharin a...@kocharin.rumailto:a...@kocharin.ru
Cc: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
On Jun 10, 2014, at 11:01 AM, Ian Hickson wrote:
(I first tried to send this last week, but it seems the es-discuss
mailman is filtering some of my mail as spam or something?)
Hello,
I've been working with jorendorff to try to write a description of the
Loader part of the ES6 spec, to
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
Is my understanding correct that the HTML spec should invoke this
algorithm when the HTML spec creates the Window object?:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-initialization
Not exactly, although if you had
Remember that ES tasks === HTML microtasks (in all implementations today; Allen
insists they are different since ES tasks are generic and do not have very many
requirements, but in reality they are the same).
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On
On Tue, Jun 10, 2014 at 2:47 PM, Frankie Bagnardi f.bagna...@gmail.com wrote:
I'd like Object.merge(source, dest), and Object.clone(source).
`Object.assign` is already in the ES6 spec.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
On 6/10/14, Ian Hickson i...@hixie.ch wrote:
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
Hi Ian; Allen.
(Also, how could step 6's substeps ever get triggered?)
Working backwards, step 5 does many things, some of which are specified
as having error conditions and exceptions, so I have to
On Tue, 10 Jun 2014, Domenic Denicola wrote:
Remember that ES tasks === HTML microtasks (in all implementations
today [...]
That doesn't sound right. If every script is always running on an ES task,
then it sounds like an ES task is neither an HTML task nor an HTML
microtask. A single HTML
On Tue, Jun 10, 2014 at 12:32 PM, Maxime Warnier mar...@gmail.com wrote:
Hi All
Do you know if it is planned or maybe in discussion for ES7 to have a
simple clone system on objects ?
There are different notations, from :
- jquery
Object.clone( [withDataAndEvents ] [,
On Jun 10, 2014, at 2:08 PM, Ian Hickson wrote:
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
Is my understanding correct that the HTML spec should invoke this
algorithm when the HTML spec creates the Window object?:
On Jun 10, 2014, at 2:33 PM, Ian Hickson wrote:
On Tue, 10 Jun 2014, Domenic Denicola wrote:
Remember that ES tasks === HTML microtasks (in all implementations
today [...]
That doesn't sound right. If every script is always running on an ES task,
then it sounds like an ES task is
On Jun 10, 2014, at 2:31 PM, Garrett Smith wrote:
On 6/10/14, Ian Hickson i...@hixie.ch wrote:
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
Hi Ian; Allen.
(Also, how could step 6's substeps ever get triggered?)
Working backwards, step 5 does many things, some of which are specified
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
By an ECMAScript Environment (and this is what Ecma-262 defines,
although it doesn't actually use that name) I mean a heap of ECMAScript
objects (and related values) that may directly reference (point to) each
other and a single thread of
From: Ian Hickson [mailto:i...@hixie.ch]
On Tue, 10 Jun 2014, Domenic Denicola wrote:
Remember that ES tasks === HTML microtasks (in all implementations today
[...]
That doesn't sound right. If every script is always running on an ES task,
then it sounds like an ES task is neither an
On 6/10/14, 9:04 PM, Domenic Denicola wrote:
How do we reconcile this with the fact that promises use microtasks in all
implementations today?
Promises in Gecko don't use microtasks (which don't even really exist in
Gecko). They use what HTML calls tasks (that is, full-on event loop
On Wed, 11 Jun 2014, Domenic Denicola wrote:
Hmm. How do we reconcile this with the fact that promises use microtasks
in all implementations today? Are they nonconformant with the spec? Or
is the spec flexible enough that e.g. PromiseTask ES tasks can be put on
a HTML microtask queue,
From: Ian Hickson [mailto:i...@hixie.ch]
Where in the ES spec are the ES jobs for promises queued up?
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-triggerpromisereactions
and
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.prototype.then;
search for
On Jun 10, 2014, at 7:21 PM, Ian Hickson wrote:
On Wed, 11 Jun 2014, Domenic Denicola wrote:
Hmm. How do we reconcile this with the fact that promises use microtasks
in all implementations today? Are they nonconformant with the spec? Or
is the spec flexible enough that e.g. PromiseTask
On Wed, 11 Jun 2014, Domenic Denicola wrote:
From: Ian Hickson [mailto:i...@hixie.ch]
Where in the ES spec are the ES jobs for promises queued up?
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-triggerpromisereactions
and
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
Regarding, Domenic's and Boris responses, I don't see why ES6 promise
related Jobs need to be translated into HTML Tasks/Microtasks at all.
The ES6 spec. takes care of creating and queueing its promise related
Jobs. The only thing HTML needs
Alex Vincent wrote:
var x = new SmallDecimal(2);
var y = new SmallDecimal(3);
[x y, x y, x == y, x = y, x = y, x != y]
valueOf doesn't work for SmallDecimal(2) == SmallDecimal(2), though. You
have to hash-cons, which kils performance.
String relational order is wrong for numeric types, to
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
EnqueueTask() step 7 is where the HTML spec would hook in and treat
different jobs as ending up in different task queues. Presumably, if
we want all promise resolutions to be treated as microtasks, then that
step would be overridden to
38 matches
Mail list logo
