From: Mark Miller [erig...@gmail.com] > On Wed, Jul 31, 2013 at 3:52 PM, Domenic Denicola > <dome...@domenicdenicola.com> wrote: >> From: Mark S. Miller [erig...@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..." _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
