Promises Consensus

Domenic Denicola domenic at domenicdenicola.com
Wed Jul 31 16:02:14 PDT 2013


From: Mark Miller [erights at gmail.com]
> On Wed, Jul 31, 2013 at 3:52 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
>> From: Mark S. Miller [erights at google.com]
>>> One thing I think Domenic is missing that I also missed at first: Once we introduce .flatMap, then we need a distinct "accepted" state that is neither "fulfilled" nor "rejected". The issue is that p.then 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 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 necessary to account for the behavior or both .flatMap and .then under AP2.
>>
>> Isn't this just what we've been calling "resolved"? As in "p is resolved q, but still pending because q is pending"?
>
> I'm sorry Domenic, but since I'm hair splitting and stated several distinctions, I need to know which "this" you refer to.

By "this" I meant the "accepted" state, and the idea that "p is accepted to q."

While I'm here, let's correct a typo: "As in 'p is resolved q..." becomes "As in 'p is resolved with q..."





More information about the es-discuss mailing list