-discuss-boun...@mozilla.org]
On Behalf Of Dean Landolt
Sent: Wednesday, April 24, 2013 12:09 PM
To: Tab Atkins Jr.
Cc: Mark S. Miller; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review)
On Wed, Apr 24, 2013 at 2:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed
On Wed, Apr 24, 2013 at 1:16 AM, Ron Buckton rbuck...@chronicles.org wrote:
* Future#then (tentatively adds the options argument in my proposal for
forcing synchronous execution of continuation)
* Future#done (tentatively adds the options argument in my proposal for
forcing synchronous
On Wed, Apr 17, 2013 at 4:46 PM, Anne van Kesteren ann...@annevk.nl wrote:
I don't find the whole who owns what discussions very interesting to
be honest. If it was up to me JavaScript would just be part of the W3C
and we would not have to deal with that layer of distraction.
I got some
From: Andreas Rossberg [rossb...@google.com]
Mark, could you summarize the rationale for this, or provide a more specific
link to the appropriate bit of the discussion you are referring to?
I'm not Mark, and he might have something more specific in mind, but this
summary was pretty helpful:
On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Andreas Rossberg [rossb...@google.com]
Mark, could you summarize the rationale for this, or provide a more specific
link to the appropriate bit of the discussion you are referring to?
I'm not Mark,
(was: Request for JSON-LD API review)
On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Andreas Rossberg [rossb...@google.com]
Mark, could you summarize the rationale for this, or provide a more
specific link to the appropriate bit of the discussion you
On Wed, Apr 24, 2013 at 2:18 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Andreas Rossberg [rossb...@google.com]
Mark, could you summarize the rationale for this, or provide a more
specific link to
their library for
pre- and post- ES6 (or later) versions.
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Dean Landolt
Sent: Wednesday, April 24, 2013 12:09 PM
To: Tab Atkins Jr.
Cc: Mark S. Miller; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API
Now, instead of a ducktest for a `then` method the promise check would
instead be specified as `instanceof Promise`.
Picking a message at random for an interjection, there is something that
seems to be missing in this discussion:
*Promises are only one kind of thenables (the asynchronous
cases
in a Future-based AMD module loader I'm tinkering with.
Ron
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Friday, April 19, 2013 6:42 PM
To: Ron Buckton
Cc: Kevin Gadd; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review)
On Fri, Apr 19
On Tue, Apr 23, 2013 at 5:16 PM, Ron Buckton rbuck...@chronicles.orgwrote:
[...] a Future-based AMD module loader I'm tinkering with.
In that case, you might want to look at
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#amd_loader_lite
and
Ecma does official HTML now.
/be
Tab Atkins Jr. wrote:
unofficial HTML version for everything.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
: Anne van Kesteren [mailto:ann...@annevk.nl]
Sent: Wednesday, April 17, 2013 8:46 AM
To: Mark S. Miller
Cc: public-script-co...@w3.org; Norbert Lindenberg; Markus Lanthaler;
Douglas Crockford; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review)
On Wed, Apr 17, 2013 at 8:29
Lanthaler; Douglas Crockford; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review)
On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
The main argument I've heard for proceeding with w3c/DOMFutures
rather than tc39/promises
On Fri, Apr 19, 2013 at 2:24 PM, Ron Buckton rbuck...@chronicles.org wrote:
My version of the PromiseResolver provides resolve/reject methods and does
not include an ‘accept’ method. My understanding of this is that
FutureResolver#accept resolves the value explicitly, while
My solution for cancellation has been to allow cancellation notifications
to be bidirectional - that is, when you subscribe to completion
notifications on a Future, you can also subscribe to cancellation
notifications. Then it's possible to cancel a given future without breaking
any other
On Fri, Apr 19, 2013 at 3:35 PM, Kevin Gadd kevin.g...@gmail.com wrote:
My solution for cancellation has been to allow cancellation notifications to
be bidirectional - that is, when you subscribe to completion notifications
on a Future, you can also subscribe to cancellation notifications. Then
I'm not sure there's a perfect solution, yeah. Cancellation is definitely
not something you want every listener to be responsible for in a
multiple-listener scenario - most scenarios I've dealt with are ones where
a single task is responsible for the lifetime of a future - deciding
whether to
On Fri, Apr 19, 2013 at 4:02 PM, Kevin Gadd kevin.g...@gmail.com wrote:
I'm not sure there's a perfect solution, yeah. Cancellation is definitely
not something you want every listener to be responsible for in a
multiple-listener scenario - most scenarios I've dealt with are ones where a
single
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Friday, April 19, 2013 3:14 PM
On Fri, Apr 19, 2013 at 2:24 PM, Ron Buckton rbuck...@chronicles.org
wrote:
Progress notifications are a bit of a mixed bag for me. My first
implementations of Future didn’t have them, but I had a
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Friday, April 19, 2013 5:18 PM
To: Kevin Gadd
Cc: Ron Buckton; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review)
On Fri, Apr 19, 2013 at 4:02 PM, Kevin Gadd kevin.g...@gmail.com wrote
On Fri, Apr 19, 2013 at 6:37 PM, Ron Buckton rbuck...@chronicles.org wrote:
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Friday, April 19, 2013 5:18 PM
To: Kevin Gadd
Cc: Ron Buckton; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review
On 17/04/2013, at 17:46, Anne van Kesteren wrote:
If it was up to me JavaScript would just be part of the W3C
and we would not have to deal with that layer of distraction.
On 17/04/2013, at 19:48, Tab Atkins Jr. wrote:
I strongly support any efforts to move JS standardization into the
On Thu, Apr 18, 2013 at 2:00 PM, Jorge jo...@jorgechamorro.com wrote:
You guys ought to be deeply embarrassed because HTML5 is *not* your child.
I don't even
--
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
[+es-discuss]
On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller erig...@google.com wrote:
Frankly, DOMFutures have nothing to do with the DOM, other than the fact
that the DOM would benefit from using them -- as would many other APIs.
There is nothing browser specific about this, and much that
On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller erig...@google.com wrote:
The main argument I've heard for proceeding with w3c/DOMFutures rather
than tc39/promises is that the DOM can't wait for tc39 to get around to
standardizing promises in ES7. But we should have our eyes open to the
On Wed, Apr 17, 2013 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller erig...@google.com
wrote:
The main argument I've heard for proceeding with w3c/DOMFutures rather
than tc39/promises is that the DOM can't wait for tc39 to get around
On Wed, Apr 17, 2013 at 4:56 PM, Mark S. Miller erig...@google.com wrote:
Hi Anne, promises were already in progress for ES7. It was the w3c that
chose to fork the effort rather than participate and provide feedback.
Okay, lets assume promises are not in the DOM specification. How soon
do you
On Wed, Apr 17, 2013 at 5:06 PM, Anne van Kesteren ann...@annevk.nl wrote:
[...]
My previous experience has been trying to get bytes in JavaScript
(mostly for XMLHttpRequest): asked from TC39 in 2006. Eventually
delivered by Khronos for WebGL. Mourned over by TC39 (and others,
myself included)
[es-discuss only fork]
Hi,
I'm forking this as I feel it surfaces an issue which I analyse as being
rooted in the ECMAScript organization. As I describe my opinion below,
please feel free to tell me I'm wrong in my analysis.
I'm sorry this is not a technical discussion, but I nonetheless
On Wed, Apr 17, 2013 at 10:28 AM, David Bruant bruan...@gmail.com wrote:
I'm also going to ask a pretty violent question, but: does it still need to
be spec'ed by ECMA? The only argument I've heard in favor of staying at ECMA
is that some people still find ISO standardization and Word/PDF
HI Anne and Mark,
You both make good points: Mark is correct when he suggests that a
DOMFuture spec will effectively undercut TC39's role in designing a
future/promise API. It will also set a precedent (one that is perhaps
already in motion) where TC39 is relegated to syntax-only enhancements
On Wed, Apr 17, 2013 at 11:27 AM, Kevin Smith zenpars...@gmail.com wrote:
HI Anne and Mark,
You both make good points: Mark is correct when he suggests that a
DOMFuture spec will effectively undercut TC39's role in designing a
future/promise API. It will also set a precedent (one that is
(was: Request for JSON-LD API review)
On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller erig...@google.com wrote:
The main argument I've heard for proceeding with w3c/DOMFutures
rather than tc39/promises is that the DOM can't wait for tc39 to get
around to standardizing promises in ES7. But we should have
On Apr 17, 2013, at 10:28 AM, David Bruant wrote:
...
Although promises were planned for ES7, they weren't part of any formal spec.
As far as I know, no recent TC39 meetings even mentioned the concurrency
strawman [2].
i don't think the mention observation is totally correct. More
On Apr 17, 2013, at 10:48 AM, Tab Atkins Jr. wrote:
On Wed, Apr 17, 2013 at 10:28 AM, David Bruant bruan...@gmail.com wrote:
I'm also going to ask a pretty violent question, but: does it still need to
be spec'ed by ECMA? The only argument I've heard in favor of staying at ECMA
is that some
On Wed, Apr 17, 2013 at 12:06 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Note that there is an official HTML version
http://www.ecma-international.org/ecma-262/5.1/
Thanks!
This apparently has bad google-juice, and is not linked prominently in
the first couple results that I look at
37 matches
Mail list logo
