From: Mark S. Miller [[email protected]] > 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 suppose that is ambiguous because you could resolve p to a non-promise-like and the behavior is a bit different. Perhaps you're proposing that "resolve p with q" will make p resolved with q, and we will additionally say either that p is accepted with q, if q is a promise-like, or fulfilled with q, if q is non-promise-like. Does that sound accurate? _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
