[+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)
Mark: It's also unfortunate and incorrect to say the w3c forked this.
This plan was fleshed out on public-script-coord and you've been part of
the evolution of the proposal ever since. I don't understand what, if
anything, you're objecting to.
On Wed, Apr 17, 2013 at 5:49 PM, Robin Berjon
[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
As someone who has been interested in Promises/Futures in JavaScript for a
number of years, I'd like to throw in my $0.02 regarding a proposed API for
Promises/Futures for thoughts:
https://gist.github.com/rbuckton/5406451
My apologies in advance as the API definitions are written using
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
Le 17/04/2013 21:03, Allen Wirfs-Brock a écrit :
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
On Apr 17, 2013, at 2:25 PM, David Bruant wrote:
Le 17/04/2013 21:03, Allen Wirfs-Brock a écrit :
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
On Tue, Apr 16, 2013 at 4:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I think these cases will be fairly common, and further, that
a good solution to the problem for DOM will be pretty useful for
general programming as well.
I agree.
I have a ton of minor feedback and questions. Sorry
On Wed, Apr 17, 2013 at 5:50 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Tue, Apr 16, 2013 at 4:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
interface EventStreamResolver {
I get the parallel with FutureResolver but this name doesn't work for
me. FutureResolver makes sense
On Wed, Apr 17, 2013 at 3:57 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
A a rule of thumb, if a library does something that can not be expressed in
the its base language there is a good chance it is extending the virtual
machine of the language and it should at least be reviewed from
On Wed, Apr 17, 2013 at 7:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Mmmm. The interesting thing about Futures is... well, I'll just link to
http://domenic.me/2012/10/14/youre-missing-the-point-of-promises/
Actually, thanks a bunch for this link. It pointed out an aspect I
hadn't
20 matches
Mail list logo
