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. > > 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
