Closed domenic closed 11 years ago
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.
No longer an issue now that polymorphic reject is dead. #9 or #16 are still a thing, though.
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?
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:
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.