Both when() callbacks can get triggered. about q HOT 5 CLOSED

FWIW, I just looked at the Q implementation a bit closer and figured out that you get this same behavior without defining when() in the descriptor at all, since the default rejector is written in exactly the same way. That is, you can comment out the line when: when in my example and still see the bad behavior.

Also, to be clear, I did these tests with version 0.8.5 as fetched via npm.

from q.

promise.when is not really the primary intended method for resolving a promise, instead you should really use either:

promise.then(onResolved,onRejected);
//or
Q.when(promise, onResolved, onRejected);

However both these exhibit the same behaviour, so that's not the problem. I've submitted a pull request which fixes this, but since makePromise is an advanced feature, I'll have to defer to the author for how it's meant to be used.

from q.

Total sidebar here:

I thought promise.when() and promise.then() were synonyms. I'm betraying my prior work experience (on E, quite a while ago) by having picked that over promise.then() in my example.

Thanks for the recommendation, and thanks for the fix.

from q.

@danfuzz, In Q, promise.when is an alias that forwards to promise.then. promise.then in turn is implemented with Q.when. Internally, this uses the "when" message. The words bear the same meaning, but the implementation is wishy-washy about which work should be used for static (Q.when) and dynamic (promise.then, (but also aliased as promise.when)). Q assimilates objects that implement "then" (thenables) into Q promises, but it does not do the same for "whenables" because such things do not exist in the wild.

It’s a bit of a mess, being stuck between the trends in JavaScript and trends in forebears like E.

My inclination is to keep Q.when and promise.then, and remove promise.when so at least you can go by the rule "what makes sense when spoken", but on the other hand, MarkM’s favoring Q(promise).when in the Concurrency Strawman, which I would like to support.

What I mean by the mnemonic, these are the natural choices of words, and the corresponding implied usage in Q.

"When A, B", Q.when(A, B)

"A then B", A.then(B)

from q.

I do really like the idea of sticking to the natural choices of words, I think it might be a nice idea to go with something like Q(promise).then though as the static version, that way they'd both be then.

from q.