Add info about non-interference of handlers about promises-spec HOT 9 CLOSED

Hi,

I'm that someone, and I just wanted to add a little context. The rule is implicit; it really only comes across if you think of the problem a certain way, otherwise it becomes a question. If you defined the rule explicitly, there'd be no question during implementation, e.g. Errors thrown from a handler will not block execution of subsequent handlers

Of course, the issue could be I just looked at the problem another way and missed the implication. Regardless, if it's open to interpretation there's room for error. Adding another point at the right place would help greatly.

from promises-spec.

@avoidwork Thanks for the additional context! Were you coming at this as a user of promises, or as an implementer of promises (or both)?

from promises-spec.

A little of both. I'm writing the tool set (implementer) which I build on of (user). No one I work with has experience with the pattern beyond jQuery's version, and ... yeah.

from promises-spec.

@avoidwork Would the insertion of the word "all" into 3.2.5.1 and .2 clarify enough?

If/when promise is fulfilled, all respective onFulfilled callbacks must execute in the order of their originating calls to then.

from promises-spec.

yup

from promises-spec.

Let's do that then, it's very easy and doesn't seem like it's overburdening the spec with non-normative language.

from promises-spec.

Sounds good to me as well. Since it doesn't seem to make the spec any less clear, and in fact, makes it more clear for at least one person, it seems like a good thing :)

from promises-spec.

I can do this when I get back to a keyboard in a bit if no one gets to it first.

from promises-spec.

Oops sorry for the double commit messages above. One is from my fork, but I decided just to make this change directly, as it seemed silly to pull request it since it was such a small change.

from promises-spec.