Resolving this would be much appreciated. Gecko recently turned on
Promises in our nightly builds, and already branched to our aurora
builds. I believe Chrome is in a similar situation.
Chrome has shipped Promises, i.e. they are enabled by default on the
current stable Chrome. So the
On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote:
Sorry for knowing little about ES consensus, is this the final decision?
Will you change it again?
Yeah, some clarity would be nice.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko
when the news
On 5 February 2014 11:17, Mark S. Miller erig...@google.com wrote:
At the end of Sept mtg, my memory of the state on entry to the meeting
agrees completely with Domenic's. On exit, my memory is
a) We had agreed to promote both the .then level and the .chain level to
ES6. (This is probably the
On 5 February 2014 12:10, Alex Russell slightly...@google.com wrote:
On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote:
I'd rather we keep separate and conflict-prone APIs in separate objects,
though. I'd rather we acknowledge that Promises are a library de-facto
However, this question actually triggered me to have a closer look at
the state of the spec (again), the outcome of which was my proposal
for a refactoring. That refactoring based .then on .chain and pulled
it from any of the core logic, thus avoiding the problems you seem to
be alluding
On Fri Feb 7 06:50 AM, Anne van Kesteren wrote:
On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote:
Sorry for knowing little about ES consensus, is this the final decision?
Will you change it again?
Yeah, some clarity would be nice.
From a user perspective, can
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Jonathan
Bond-Caron jbo...@gdesolutions.com
What seems like a preferred api / pattern from an ecma PoV to serially
execute promises?
Promise.prototype.then
https://github.com/kriskowal/q#sequences
On Fri, Feb 7, 2014 at 8:20 AM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
On Fri Feb 7 06:50 AM, Anne van Kesteren wrote:
On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote:
Sorry for knowing little about ES consensus, is this the final decision?
Will you
The first goal listed for ecmascript modules:
- Obviate need for globals
(http://wiki.ecmascript.org/doku.php?id=harmony:modules).
Ironically, the current proposal for module loading includes a global
System and possibly Loader. Worse, it seems like the global System is
explicitly expected
Kevin Smith wrote:
If I may interject some opinions on process...
Sure, it's es-discuss. Plus, you've earned your spurs.
I'm not sure how this fits in with the new post-ES6 process, but from
this one outsider's point of view:
- A formal set of design goals should be completed and agreed
On Feb 5, 2014, at 9:30 PM, Michael Dyck wrote:
When I take the ECMAScript grammar and expand its abbreviations as outlined
in section 5.1.5, I get a grammar with lots of unreachable nonterminals
(i.e., symbols that can't appear in any sentential form derived from Script
or Module).
For
Le 07/02/2014 22:05, Brendan Eich a écrit :
Kevin Smith wrote:
- A *working* implementation should be created and solutions to
real-world use cases should be programmed using the design before any
spec language is authored. Spec-language is a poor medium for
communicating both design intent
David Bruant wrote:
Le 07/02/2014 22:05, Brendan Eich a écrit :
Kevin Smith wrote:
- A *working* implementation should be created and solutions to
real-world use cases should be programmed using the design before
any spec language is authored. Spec-language is a poor medium for
An area of challenge in JavaScript is the ability to detect a JavaScript
objects implemented class name. I have done this in the past with some
success by parsing the objects constructor but I know that this depends on
the Object constructor being named and is not very efficient as it requires
the
o.constructor.name seems good?
From: Timothy Quinnmailto:tim.c.qu...@gmail.com
Sent: 2/7/2014 22:26
To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Efficient determination of implemented class name
An area of challenge in JavaScript is the
LOL. I did not realize that was implemented already :)
Thanks,
- Tim
On Fri, Feb 7, 2014 at 10:28 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
o.constructor.name seems good?
--
From: Timothy Quinn tim.c.qu...@gmail.com
Sent: 2/7/2014 22:26
To:
Digging into ECMA-262, I cannot find this noted but it appears to be
implemented in V8 and SpiderMonkey.
Mozilla states this as
non-standardhttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/nameso
I am guessing that its not documented in ECMA-262.
Is this
Function name is in the latest ES6 draft.
On Fri Feb 07 2014 at 11:15:31 PM, Timothy Quinn tim.c.qu...@gmail.com
wrote:
Digging into ECMA-262, I cannot find this noted but it appears to be
implemented in V8 and SpiderMonkey.
Mozilla states this as
Sweet. Thanks for the quick responses =D
On Fri, Feb 7, 2014 at 11:24 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
Function name is in the latest ES6 draft.
On Fri Feb 07 2014 at 11:15:31 PM, Timothy Quinn tim.c.qu...@gmail.com
wrote:
Digging into ECMA-262, I cannot find this noted
19 matches
Mail list logo
