Promise.cast and Promise.resolve

Paolo Amadini paolo.02.prg at amadzone.org
Wed Jan 29 04:45:42 PST 2014


On 29/01/2014 5.12, Kris Kowal wrote:
> In this case, a half pursuit of type purity is a side quest at the
> expense of users. Having two ways to resolve and two ways to observe a
> promise is unnecessarily confusing. In my experience, one method like
> "then", that unwraps recursively, and one function, like "Promise.cast",
> that automatically lifts if necessary, and "then" handlers that return
> into the waiting hands of "Promise.cast" are coherent and ergonomic.
> Having a choice between "cast" and "resolve" and a choice between "then"
> and "chain", will leave developers unnecessarily confused and worried
> all the while they use or abandon Promises as too subtle.

As an imperative programmer, I confirm I'm left worried and confused ;-)

But I understand that functional programming might need more complexity.
I would be less confused if functionality that is only relevant for
functional programming would be separate and inaccessible by default,
even if supported and optimized at the implementation level.

For example:

```js
let p1 = FunctionalPromise.accept(...)
FunctionalPromise.chain(p1, ...)
```

And no "Promise.accept" or "p1.chain" methods to be chosen over
"Promise.cast" and "p1.then".

Paolo


More information about the es-discuss mailing list