On 05/02/2014 9.43, Brendan Eich wrote:
> Can we regain consensus on the September status quo ante, minus any "do
> both" half-hearted compromises that don't work? Mark, what do you think?

For what it's worth, I've been planning to file a bug on GitHub before
I saw the most recent conclusion, that dispelled my concerns.

My conclusion, deriving from the explanations of the design that I
received on this list (very informative by the way, thanks!) was that
"Promise objects for imperative and functional use should be distinct".

In fact, in the design I was concerned about, when calling a function
that returns a Promise object generated by code that uses "imperative"
promises (i.e. expects "then" to be used), a consumer that works with
"functional" promises (i.e. uses "chain") cannot reasonably know which
Promise type is returned, potentially leading to subtle bugs.

Consider this scenario, with a typical documentation of an opaque
imperative library: "The getResponse() method will return a Promise
resolved with the response string." Will getResponse return a
Promise(String) or a Promise(Promise(String))?

It may actually return one or the other. To be sure about the type when
used in a functional context, the promise will require unwrapping at
the boundary between the two usage styles. Using the same object for
both uses might lead to confusion and forgetting the unwrapping.

I think the conclusion of using two distinct objects for that
(with the other named FuctionalPromise, Future, or anything else)
resolves the issue. Imperative Promise implementations may use those
alternative primitives internally.

Paolo

On 05/02/2014 9.43, Brendan Eich wrote:
> Can we regain consensus on the September status quo ante, minus any "do
> both" half-hearted compromises that don't work? Mark, what do you think?

For what it's worth, I've been planning to file a bug on GitHub before
I saw the most recent conclusion, that dispelled my concerns.

My conclusion, deriving from the explanations of the design that I
received on this list (very informative by the way, thanks!) was that
"Promise objects for imperative and functional use should be distinct".

In fact, in the design I was concerned about, when calling a function
that returns a Promise object generated by code that uses "imperative"
promises (i.e. expects "then" to be used), a consumer that works with
"functional" promises (i.e. uses "chain") cannot reasonably know which
Promise type is returned, potentially leading to subtle bugs.

Consider this scenario, with a typical documentation of an opaque
imperative library: "The getResponse() method will return a Promise
resolved with the response string." Will getResponse return a
Promise(String) or a Promise(Promise(String))?

It may actually return one or the other. To be sure about the type when
used in a functional context, the promise will require unwrapping at
the boundary between the two usage styles. Using the same object for
both uses might lead to confusion and forgetting the unwrapping.

I think the conclusion of using two distinct objects for that
(with the other named FuctionalPromise, Future, or anything else)
resolves the issue. Imperative Promise implementations may use those
alternative primitives internally.