Re: Promises: Auto-assimilating thenables returned by .then() callbacks: yay/nay?

On Thu, May 2, 2013 at 1:51 PM, Mark S. Miller <erights@google.com> wrote:
> On Thu, May 2, 2013 at 1:27 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Thu, May 2, 2013 at 12:55 PM, Domenic Denicola
>> <domenic@domenicdenicola.com> wrote:
>> > From: Tab Atkins Jr. [jackalmage@gmail.com]
>> >> While I clear that up (since the naming and the behavior are not
>> >> inconsistent, which is extremely confusing),
>> >
>> > This isn't really true. The `acceptCallback` is the callback called when
>> > the promise is fulfilled ("accepted" in the DOMFuture promise library). It
>> > uses `resolve` semantics to process its return values, but it would need to
>> > do that anyway, in order to get different behavior for promises and for
>> > values. You need to distinguish between the condition on which the callback
>> > is called, and the behavior of the callback with respect to its return
>> > values.
>>
>> Yes, the first callback to .then() needs to use resolve semantics, so
>> you can return either a plain value or a future.  Right now, though,
>> "resolve semantics" means "recursively flatten nested futures until
>> you end up with a single future holding a plain value".
>>
>> I thought I'd gotten several people, including you and Mark Miller, to
>> acknowledge that recursive flattening was not necessary for native
>> promises,
>
>
> Recursive flattening is not necessary, possible, or meaningful for promises,
> since we've carefully avoided introducing an explicit unconditional lift
> operator which would enable the creation of a promise-for-promise. Since
> DOMFutures are apparently proceeding on their own, prior to achieving any
> consensus at TC39, promises will view DOMFutures simply as thenables and
> assimilate them recursively when it encounters them.
>
> As for whether DOMFutures flatten, unwrap, or assimilate promises, I leave
> that to you, since it seems we have no choice but to leave that to you
> anyway. I find it a terrible shame that we were not able to repair this
> forking of our efforts.

The WebApps WG at W3C has long operated under a "change then review"
policy, and I think that's the only thing happening here. People are
fiddling around with the DOMFuture drafts in order to see what works
and what doesn't. I don't think any decisions or concensus has been
reached about anything at this point. Well, other than "We should
create a standardized promise API".

At least I certainly don't treat the DOMFuture drafts as anything
authoritative that we'll be shipping in Firefox. At most we'd enable
it on Aurora builds in order to let developers play around with it and
provide feedback about how well it works. I.e. the only goal would be
to generate exactly the type of discussions we're having here, but
with a little more data/code to back it up.

So I agree with Tab, there's not really anything to be fighting over here.

As long as TC39 produces a promise API (called "Future" or otherwise)
within a reasonable time, then that's what I'd use as authoritative
source. That said, since there are no such drafts yet, I don't see any
reason not to continue to noodle over the Future API as drafted in the
DOM4 drafts and on the DOMFuture github.

So, with that said, I completely agree with you that recursive
flattening is neither necessary or possible.

I do think that the question asked in the summary of this thread is a
very important one, and I'm glad to see that we're getting to it:
"Should a thenable returned from a .then() callback be assimilated
into the original Future?" I think the answer is the same as to the
question "Should a thenable passed to FutureResolver.resolve() be
assimilated into the original Future?"

But I don't think it's at all obvious that the answer to that question
should be "yes".

Answering "yes" to that question means that thenables/promises from
other libraries automatically integrates with Futures, which is really
nice. But it also means that we are forever making "then" a magical
property name the same way that "__proto__" is which I think is a very
big problem.

Answering "no" means that any time you want to pass a non-Future
thenable as a result of a future, you have to explicitly wrap a Future
around it. This is certainly inconvenient, but we could lessen that
burden by adding a Future.from() function which automatically converts
a thenable from any library into a Future.

/ Jonas

Received on Thursday, 2 May 2013 22:25:16 UTC