Terminology for polymorphic operations

[domenic]

In #10, I'm starting to see the light of polymorphic resolve and reject. Still, that leaves us with a terminology and pedagogy issue.

Can anyone think of something better than the following?

• Change Promises/A+ to use "broken" as the state name opposite to "fulfilled." (Thus onBroken, etc.)
• new Promise(function (resolve, reject) { ... }) with "resolve" having the polymorphic fulfill-or-break behavior, and "reject" having the polymorphic break behavior.

This seems conceptually reasonable but pedagogically tricky:

• "When you resolve a promise, it may become fulfilled or broken or stay pending forever."
• "When you reject a promise, it may become broken or stay pending forever."
• "Resolving a promise with a non-promise will fulfill it."
• "Rejecting a promise with a non-promise will break it."
• "Resolving a promise with another promise will cause it to adopt the other promise's state."
• "Rejecting a promise with another promise will cause it to be broken with the other promise's fulfillment value or breakage reason, or stay pending forever if the other promise does." (This line is still very weak. Breakage reason!? And why isn't it as succint as the previous one?)

---

I'm not sure this is OK, from a ecosystem and pedagogy point of view. Even if it's less theoretically pure, I still see the attraction of simple { fulfill, reject } methods that do allow promises-for-promises into the system.

[briancavalier]

This seems solvable, given that it was relatively simple to specify polymorphic throw using language parallel to polymorphic return over in promises-aplus/promises-spec#66. I don't have any answers right now, but I'll think about it.

[domenic]

No longer an issue now that polymorphic reject is dead. #9 or #16 are still a thing, though.