way that developer tooling cannot otherwise recover.
However, since we do not yet have experience with this tooling it is hard
to say. Given the purpose of this repository -- a minimal-ish compatible
subset of expected standard ES7 promises, adequate for DOM's immediate
needs -- we should leave
While I can agree that "monitor" feature (that's proposed instead of `done`)
has some benefits, I see it only as an aid for developers that are
inexperienced with promises, or as a fallback for those experienced.
It looks more as a smart add-on, which to be complete can't be
My colleagues and I are working on an extension for Chrome Web Inspector
that can communicate with promise libraries, particularly Q, over the
window message port. The tool, which will be renamed and rewritten before
it is ready for general use, adds a Promises tab to Web Inspector that
shows all
> As far as I know, the current plan is still that devtools should
> handle swallowed exceptions, since we got rid of .done() some time
> ago. Plans may have changed without me knowing, though!
>
> ~TJ
>
I'd be interested in more detail since I think this will be an important
usability issue. Ar
On Wed, Sep 4, 2013 at 7:34 AM, Kevin Smith wrote:
> This looks like good work. I like the name "cast" in particular, as I can
> imagine a future casting operator which provides sugar for the cast function
> defined on a constructor.
>
> The only concern I have is over error-swallowing. What's t
This looks like good work. I like the name "cast" in particular, as I can
imagine a future casting operator which provides sugar for the cast
function defined on a constructor.
The only concern I have is over error-swallowing. What's the approach for
this minimal API?
{ Kevin }
On Tue, Sep 3, 2013 at 6:37 AM, Anne van Kesteren wrote:
> As many of you hopefully know, we're trying to nail down the design of
> promises in JavaScript so we can declare consensus on it and start
> shipping it in implementations. If you're interested in the
> particular
As many of you hopefully know, we're trying to nail down the design of
promises in JavaScript so we can declare consensus on it and start
shipping it in implementations. If you're interested in the
particulars I strongly recommend reading through
https://github.com/domenic/promises-unwra
Er, replace `notAcceptedAndNotResolved` with `resolvedButNotAccepted`. X_x
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
From: Mark S. Miller [erig...@google.com]
> No. Assuming that p and q are both promises and that q is pending, p is
> resolved to q when either p adopts q or p accepts q. From the .then
> perspective these are the same, so we'd say p follows q or p is resolved to
> q. In n
t; It seems there might be consensus on that now? It just seems safer and
> loads simpler to start out with deploying a subset that's more
> commonly agreed upon.
This remained unanswered for some reason. Promises are spreading like
wildfire through Gecko and B2G now. Chrome is implement
On Fri, Aug 2, 2013 at 2:42 PM, Mark Miller wrote:
> On Fri, Aug 2, 2013 at 2:28 PM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
>> From: Mark S. Miller [erig...@google.com]
>>
>> > A good start would be to convert
>> https://github.co
On Fri, Aug 2, 2013 at 2:28 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> From: Mark S. Miller [erig...@google.com]
>
> > A good start would be to convert
> https://github.com/promises-aplus/promises-tests to test262 form,
> extending test262 in the process
From: Mark S. Miller [erig...@google.com]
> A good start would be to convert
> https://github.com/promises-aplus/promises-tests to test262 form, extending
> test262 in the process in order to accommodate async testing. Any volunteers?
If someone does the latter (preferably with a sim
A good start would be to convert <
https://github.com/promises-aplus/promises-tests> to test262 form,
extending test262 in the process in order to accommodate async testing. Any
volunteers?
In the meantime, <https://github.com/promises-aplus/promises-tests> itself
is still a good st
David Bruant wrote:
I believe that to a large extent, the risk of both misunderstanding of
intent and misexpression understood intent would be largely reduced by
a test suite.
+∞
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mo
ndard. There are two
ways in which this can happen:
* misunderstanding of intent
* misexpression of (even perfectly-)understood intent.
1) What should tc39 do quickly, to unblock the DOM's need for promises
and avoid a design fork?
I apologize for being annoyingly insistent with this, but:
On Thu, Aug 1, 2013 at 8:25 PM, Tab Atkins Jr. wrote:
> On Thu, Aug 1, 2013 at 11:27 AM, Mark S. Miller wrote:
>> For #2, since whatever DOM does quickly becomes a compat constraint on all
>> future decisions, DOM should take the minimum subset of #1 which actually
>> meets their short term needs
x27;d like the definition to be: (a) a Promise or subtype, or (b) a
>> branded non-Promise (with the branding done via Symbol or similar).
>> Promises/A+ wants the branding to be done via a method named "then"
>> (the "thenable" concept).
>>
>> This, unfo
On Thu, Aug 1, 2013 at 11:27 AM, Mark S. Miller wrote:
> There are three questions here, which need to be settled in roughly this
> chronological order:
> 1) What should tc39 do quickly, to unblock the DOM's need for promises and
> avoid a design fork?
> 2) What should DOM d
On Thu, Aug 1, 2013 at 11:26 AM, Tab Atkins Jr. wrote:
> On Thu, Aug 1, 2013 at 11:04 AM, Mark S. Miller
> wrote:
> > Between Tab's answer and mine, we see the two issues one might mean by
> > "branding".
>
> No, there's only the one concept. If you mean anything other than
> "type detection via
On Thu, Aug 1, 2013 at 11:04 AM, Mark S. Miller wrote:
> Between Tab's answer and mine, we see the two issues one might mean by
> "branding".
No, there's only the one concept. If you mean anything other than
"type detection via properties on the instance or its prototype
chain", then I don't thin
in the other thread it causes a bunch of
> > headaches to get that correct, and since we already decided (I
> > believe) to not break with existing practice we could ship the subset
> > that is that and figure out the superset-promise-that-works-for-monads
> > later. That might
calling .then.
On Thu, Aug 1, 2013 at 10:43 AM, Tab Atkins Jr. wrote:
> On Thu, Aug 1, 2013 at 10:33 AM, Juan Ignacio Dopazo
> wrote:
> > If then() deep flattens, flatMap() only flattens one level and promises
> > assimilate thenables, is branding really necessary?
>
>
.then's callback returns a
> non-promise, the promise it already returned accepts that non-promise.
>
> That's why I included assimilation in the mix. If then() deep flattens
promises there's no difference with assimilation of thenables. Only
flatMap() could need to know if som
On Thu, Aug 1, 2013 at 10:33 AM, Juan Ignacio Dopazo
wrote:
> If then() deep flattens, flatMap() only flattens one level and promises
> assimilate thenables, is branding really necessary?
The concept of "thenable" *is* branding. It's just branding with a
short, simple s
e promise it already returned accepts that non-promise.
On Thu, Aug 1, 2013 at 10:33 AM, Juan Ignacio Dopazo
wrote:
> If then() deep flattens, flatMap() only flattens one level and promises
> assimilate thenables, is branding really necessary?
>
> Juan
>
> __
If then() deep flattens, flatMap() only flattens one level and promises
assimilate thenables, is branding really necessary?
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
> believe) to not break with existing practice we could ship the subset
> that is that and figure out the superset-promise-that-works-for-monads
> later. That might also give us some insight into how many people will
> want to wrap promises to make the monad-suitable.
Let's not reopen thi
ant to wrap promises to make the monad-suitable.
--
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
valent internal magic. "settle" means "fulfill or reject".
"resolve" means "adopt or fulfill, depending on whether the value is a
promise-like or not" (in other words, what the resolver's resolve()
method does). "adopt" means fulfilling or reje
will not yet fire. When
>>> q becomes fulfilled or rejected, then p becomes fulfilled or rejected and
>>> p.then fires. Thus, p is following q. So when p and q are both promises, p
>>> follows q when p is accepted to q or when p adopts q. This hair splitting
>>
e: (a) a Promise or subtype, or (b) a
>> branded non-Promise (with the branding done via Symbol or similar).
>> Promises/A+ wants the branding to be done via a method named "then"
>> (the "thenable" concept).
>
> I suggest an @@isPromise builtin symbol, wh
or rejected, then p becomes fulfilled or rejected and
> p.then fires. Thus, p is following q. So when p and q are both promises, p
> follows q when p is accepted to q or when p adopts q. This hair splitting
> goes beyond any previous conversations I've had with anyone, but becomes
ith the branding done via Symbol or similar).
> Promises/A+ wants the branding to be done via a method named "then"
> (the "thenable" concept).
>
> This, unfortunately, goes directly against TC39 practices in a number
> of other areas, such as iterators, where we d
does not fire until the
> promise p is fulfilled or rejected. If q is pending, and p is accepted to q,
> then p.flatMap will fire but p.then will not yet fire. When q becomes
> fulfilled or rejected, then p becomes fulfilled or rejected and p.then fires.
> Thus, p is following q. So
On Wed, Jul 31, 2013 at 12:48 PM, Juan Ignacio Dopazo
wrote:
> Does this all mean that you're ok with having promises-for-promises?
I've always been okay with that. ^_^ This consensus details how to
handle nested promises (use .flatMap()) *and* how to ignore that and
just get
Does this all mean that you're ok with having promises-for-promises?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
dopt"
>> means accepting or rejecting with the same value as the adopted promise. If
>> I should be using better terms, let me know.
>
> Thanks for the clarifications :). I think this is a bit confusing because it
> is at odds with commonly-used terminology, from DOM Promi
se. If I should be
> using better terms, let me know.
Thanks for the clarifications :). I think this is a bit confusing because it is
at odds with commonly-used terminology, from DOM Promises and Promises/A+, but
at least now things are defined and used in a self-consistent way. Much
appreci
ther words, what the resolver's resolve()
method does). "adopt" means accepting or rejecting with the same
value as the adopted promise. If I should be using better terms, let
me know.]
Heya! I, Mark, and others have been hashing out our remaining
differences on Promises privately, and
Just some terminology questions for this new proposal...
From: Tab Atkins Jr. [jackalm...@gmail.com]
> whatever p resolves to, gets passed to the flatMap() callbacks.
What does "resolves" mean in this context? I don't believe you are using it in
the same way that it is used
Heya! I, Mark, and others have been hashing out our remaining
differences on Promises privately, and are all happy with each other
now, with only two remaining issues to be decided in a larger
audience. Anne says that we should be able to get DOM Promises on
track with this consensus if we
Thanks for making these issues clearer to me Mark. I am
beginning to get some idea of the problems that JS promises face
given that they must have an object-like appearance.
I like the fact that in E, promises "just work" and I think of
Joule as a language where every value is a p
Hi Bill,
I think I know what you mean by these terms, and what I think you mean is
correct ;). But given the history of promises and futures, you make two
unfortunate and confusing terminology choices: "forced" and "wait".
Instead, E promises, like all JS promises, are inh
Let me take a crack at describing E's support for promises.
E has two modes for sending a message to an object. There is the
immediate send and the eventual send. If the Object is an
unresolved promise the immediate send will trap. (A promise can
be forced to resolve using the
Mark S. Miller wrote:
On Wed, Nov 14, 2012 at 9:25 AM, Kevin Smith mailto:khs4...@gmail.com>> wrote:
I think you meant "optimally colored bikeshed," but OK.
Ouch : )
Names are important. Especially when it comes to something as
potentially confusing
Andreas Rossberg wrote:
On 12 November 2012 16:43, Mark S. Miller wrote:
The shift back to "when" clearly failed to achieve consensus.
FWIW, I think "then" is better, because "when" sounds as if it should
be passed some kind of predicate or condition. It just doesn't read
very natural when
On 14 November 2012 20:37, Tom Van Cutsem wrote:
> I still think futures connote strongly with blocking synchronization. If
> we'd add a concept named "future" to JS on the grounds that the same concept
> exists in Java and C++, developers will reasonably expect a blocking
> future.get() method.
same
> concept exists in Java and C++, developers will reasonably expect a
> blocking future.get() method.
>
> In my experience, the term "promise" is much more associated with
> non-blocking synchronization through .then or .when callback chaining
> (although ironical
"promise" is much more associated with
non-blocking synchronization through .then or .when callback chaining
(although ironically the name derives from Argus, which featured blocking
promises. Argh! :-)
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
up.
If I were teaching this stuff, I wouldn't start with promises. I would
start with futures and show how they are like callbacks++. That's what
most users are looking for to begin with anyway. Only after we'd mastered
futures would we talk about promises and their three st
David Bruant wrote:
What's the error forwarding/handling story for tasks?
That's the real beauty: try-catch and yield with thrown exceptions from
resumed generators compose just as you'd expect.
/be
___
es-discuss mailing list
es-discuss@mozilla.or
On Wed, Nov 14, 2012 at 12:48 PM, Mark S. Miller wrote:
>
>
>
> On Wed, Nov 14, 2012 at 9:28 AM, Rick Waldron wrote:
>
>>
>>
>>
>> On Wed, Nov 14, 2012 at 11:25 AM, Domenic Denicola <
>> dome...@domenicdenicola.com> wrote:
>>
>>> Why go purposefully against the existing terminology of the JavaSc
On 14 November 2012 18:41, Mark S. Miller wrote:
> Either way, Scala's
> unfortunate choice clearly violates this history in a confusing manner, so
> I'd classify it as #4. Let's not repeat Scala's mistake.
Just to reiterate, it's not just Scala, but more importantly also C++,
Java (to some exten
On Wed, Nov 14, 2012 at 9:28 AM, Rick Waldron wrote:
>
>
>
> On Wed, Nov 14, 2012 at 11:25 AM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
>> Why go purposefully against the existing terminology of the JavaScript
>> ecosystem? Just say “deferred” where you have “promise” and “promi
On Wed, Nov 14, 2012 at 9:25 AM, Kevin Smith wrote:
>
> I think you meant "optimally colored bikeshed," but OK.
>>
>
> Ouch : )
>
> Names are important. Especially when it comes to something as potentially
> confusing as promises and futures.
>
I agree t
r libraries using this existing
terminology.
Rick
> *From:* Kevin Smith
> *Sent:* November 14, 2012 11:23
> *To:* David Bruant
> *CC:* Mark S. Miller, EcmaScript
> *Subject:* Re: Promises
>
>
> If the second argument is optional, it's possible to have both one-arg
> I think you meant "optimally colored bikeshed," but OK.
>
Ouch : )
Names are important. Especially when it comes to something as potentially
confusing as promises and futures.
- Kevin
___
es-discuss mailing list
es-discuss@m
From: Kevin Smith [khs4...@gmail.com]
Sent: Wednesday, November 14, 2012 11:41
>> Why go purposefully against the existing terminology of the JavaScript
>> ecosystem? Just say “deferred” where you have “promise” and “promise” where
>> you have “future” and you avoid needless confusion and confli
> Why go purposefully against the existing terminology of the JavaScript
> ecosystem? Just say “deferred” where you have “promise” and “promise” where
> you have “future” and you avoid needless confusion and conflict.
>
I prefer to find the optimal solution first and then consider migration
costs
use it.
From: Kevin Smith
Sent: November 14, 2012 11:23
To: David Bruant
CC: Mark S. Miller, EcmaScript
Subject: Re: Promises
If the second argument is optional, it's possible to have both one-arg and
two-arg styles in the same API.
What do people think about this idea?
Maybe - minim
thinking:
// Creates a new promise
let promise = new Promise();
// Resolves the promise (ala Q)
promise.resolve(value);
// Rejects the promise (ala Q)
promise.reject(value);
// A handle to the eventual value of the promise
promise.future;
// The
ent async operations, I've never
read code more elegant than what Q.all offers.
What about task.js's join?
https://github.com/mozilla/task.js/blob/master/examples/read.html#L41
I feel it's pretty much equivalent. Maybe slightly less verbose. I'd
write the same code with p
Le 11/11/2012 14:44, Kevin Smith a écrit :
Is the following a counter-example?
On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller mailto:erig...@google.com>> wrote:
Hi David, thanks for your thoughtful post. I've always used
the two-arg form of .then[1], but your post makes
languages, a semi-colon is a language construct to separate 2 steps in
an algorithm and mean "do this then that".
I used .then because of my experience with Q, but if "when" is more
accurate, I'll be fine with when.
On Fri, Nov 9, 2012 at 4:33 AM, David Bruant <
t's pretty much equivalent. Maybe slightly less verbose. I'd
write the same code with promises as:
Q.all(read("sleep.html"), read("read.html")).then(function(f1, f2){
out.innerHTML += "sleep.html: " + (f1.responseText.length) +
f code like that.
I did too. If a library has a callback style, this boilerplate is
necessary, but if a library naturally has promises, it's fine.
The good news is that with only a bit of boilerplate code, one can work
with one or the other style. Things would be better, but c
... and waste battery with these libraries [3].
Reading the thread again, is this really the primary motivation for adding promises? I
don't see how the energy issue gets noticeably addressed, and so it sounds like, indeed,
"you can always build a promise library on top of the current APIs.&q
above, that promises are not a
performance construct. I largely agree for today's browser scenario.
Interestingly, a built-in may enable optimizations that a library cannot -- I'm
curious as to the Node community's take. They've done some cool benchmarking,
and I can see exte
On 12 November 2012 16:43, Mark S. Miller wrote:
> The shift back to "when" clearly failed to achieve consensus.
FWIW, I think "then" is better, because "when" sounds as if it should
be passed some kind of predicate or condition. It just doesn't read
very natural when taking continuations.
/Andr
e has
>> > long been using those same terms to distinguish traditional "futures",
>> > which
>> > provide a .get() method blocking the calling thread and returning the
>> > future's value when ready (as in e.g. Java), from "promises", wh
On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller wrote:
> [...] In my code and in my Q specs <
> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency> and
> implementations <
> http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/makeQ.js>,
> I have been using "wh
I *really* don't want to wade deep into these waters, but I'll respond a bit
here to correct errors:
On Nov 11, 2012, at 9:02 PM, Leo Meyerovich wrote:
> I've been lurking on this thread and am somewhat confused. Is the motivation
> for promises a needed expressive pr
Leo Meyerovich wrote:
Hopefully there is more discussion going on in backchannels here..
Not that I know of. Your summary messages seem spot-on to me (but alas
they aren't threaded -- subjects diverged).
Have you checked out http://taskjs.org/ yet? Builds on ES6 generators
(prefigured by ES
ding that comes with it
> off-the-shelf. Also, the lack of a built-in Q.all really doesn't promote good
> code when it comes to event synchronization.
> Oh yes, of course, you can always build a promise library on top of the
> current APIs, blablabla... and waste battery with th
I've been lurking on this thread and am somewhat confused. Is the motivation
for promises a needed expressive primitive, updating the standard library to
have asynchronous calls and structure them via promises, sugar, or something
else? I assume it's not to proscribe one particula
> Is the following a counter-example?
>
> On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller wrote:
>
>> Hi David, thanks for your thoughtful post. I've always used the two-arg
>> form of .then[1], but your post makes a strong case for more often using
>> separate one-arg .then and .fail calls. I say
On Sat, Nov 10, 2012 at 11:22 AM, Kevin Smith wrote:
>
> return AFS.stat(path)
>>.fail(error => null) // map failure to success condition
>>.then(stat =>
>>
>>if (!stat)// Path doesn't exist - create the directory
>>return AFS.mkdir(path);
>>else if (stat.i
> return AFS.stat(path)
>.fail(error => null) // map failure to success condition
>.then(stat =>
>
>if (!stat)// Path doesn't exist - create the directory
>return AFS.mkdir(path);
>else if (stat.isDirectory())// done already
>return 'nothing t
On further thought, I'm not so sure. Consider this code, which creates a
directory if it doesn't already exist and then logs "done".
return AFS.stat(path).then(stat => {
if (!stat.isDirectory())
throw new Error("Path is not a directory.");
}, error => {
// Path doe
Kevin Smith wrote:
I think arrow functions make the two-arg form considerably more
aesthetically pleasing.
Agreed. The single-parameter name can help avoid the "anonymous
functions separated by comma" problem too.
/be
___
es-discuss mailing list
es
David Bruant wrote:
Personally, to synchronize different async operations, I've never read
code more elegant than what Q.all offers.
What about task.js's join?
https://github.com/mozilla/task.js/blob/master/examples/read.html#L41
Generators + promises = tasks
Another idea: log such transformed errors, or automate matching of handled failed promises
against generated failed promises.
What we really need, as mentioned by Kris Kowal on Twitter recently, is the ability to
*un*-console.log something. That is, we want to log unhandled rejections for the
> p1.then(val => doStuff)
>> .catch(err => console.error(err));
>>
>
> Nice: +1
>
On further thought, I'm not so sure. Consider this code, which creates a
directory if it doesn't already exist and then logs "done".
return AFS.stat(path).then(stat => {
if (!stat.isDirectory())
> We have found this to be more expressive as well. Especially in ES5
> environments, where we can use Q's alias of `catch` instead of `fail`:
>
> p1.then(val => doStuff)
> .catch(err => console.error(err));
>
Nice: +1
> However, I see a lot of value in "when" as a word still. "Then" makes
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Mark S. Miller
Sent: Friday, November 9, 2012 08:33
> Hi David, thanks for your thoughtful post. I've always used the two-arg form
> of .then[1], but your post makes a strong case for more often using separ
is experience.
>>> It's related to my own writing style and I don't mean that the rest is
>>> useless and should be thrown away, but the subset I'll be covering here has
>>> proven to be sufficient to my needs for several months.
>>>
>>>
uld be thrown away, but the subset I'll be covering here has
>> proven to be sufficient to my needs for several months.
>>
>> I would be interested if others could share their experience if they had
>> a different way of using promises.
>>
>
> I also used Q
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Claus Reinke
Sent: Friday, November 9, 2012 09:07
> Another idea: log such transformed errors, or automate matching of handled
> failed promises against generated failed pr
eded. That refactoring fails
if 'then's are used for failure callbacks, and using 'fail' would make
that more obvious.
# Debugging
It's been said in other messages, one part where Q promises fell short
was debugging. With thrown errors, if you uncatch one, your
devtools
everal months.
>
> I would be interested if others could share their experience if they had a
> different way of using promises.
>
I also used Q (a slightly older version) for several months before removing
it because of cost/benefit.
>
> # the Q API
> ## A Q Deferred is a {p
d to replace all my uses of "when" with "then" and declare this
terminology issue over.
Btw, above I tried using your one-arg .then and .fail style. I think this
worked well.
On Fri, Nov 9, 2012 at 4:33 AM, David Bruant wrote:
> [...]
> ## Q.all
> My favorite f
It's related to my own writing style and I don't mean that the rest is
useless and should be thrown away, but the subset I'll be covering here
has proven to be sufficient to my needs for several months.
I would be interested if others could share their experience if they had
recent v0.8 rollouts and
that's definitely a good decision :)
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Promises-tp34648686p34655959.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
On Nov 8, 2012, at 6:45, "Mariusz Nowak"
wrote:
> Q implementors spotted that issue, and provided `done` (initially named as
> `end`) function. Which helps to work with that issue:
>
> promise.then(function () {
> // process the value
> }).done(); // Sugar for above
>
> Still in Q (as far I as
s, if a rejection is not observable via error
> listeners at the time when error listeners should be called, then an
> unhandled error should be thrown by the runtime.
>
> In my usage of promises I have never wanted anything other than this
> behavior.
>
>
I think sourc
> > provide a .get() method blocking the calling thread and returning the
> > future's value when ready (as in e.g. Java), from "promises", which only
> > provide a non-blocking "when" or "then" method requiring a callback,
> never
> >
w MarkM dislikes the use
> of these terms to distinguish synchronization from resolution, as he has
> long been using those same terms to distinguish traditional "futures", which
> provide a .get() method blocking the calling thread and returning the
> future's value wh
vely short timeframe
>> 2. Once we have DOMPromises implemented, we advocate broader
>> use throughout DOM APIs.
>> 3. Introduce ES7 Promises as a compatible subset of DOMPromises
>>
>
> I agree with this approach provided TC39 (not just you) keeps tracking and
&g
201 - 300 of 371 matches
Mail list logo
