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.

Sigh.  You're the only one who is making a big deal of this "forking".
 Please stop, and let's please continue to discuss what this means for
*Futures*, since that's the spec that *actually exists*, as opposed to
the hypothetical tc39 promises spec that you keep alluding to but
haven't written down anywhere.  If you want to influence the design of
promises, either interact with the Futures spec, or write the Promises
spec properly.  I'm not going to interact with you if you keep
objecting in theoretical terms, referring to specs that don't yet
exist.

Given that a lot of DOM APIs are going to be returning Futures by the
time you get around to speccing Promises, there's going to be
significant pressure to match behavior; otherwise you force authors to
distinguish between the semantics of things returned by "DOM" and
things returned by "JS", when the distinction is meaningless to most
authors.  (The history of this with regards to Array and the various
DOM Array-like structures neatly shows how much pain this kind of
disconnect causes.)

~TJ

Received on Thursday, 2 May 2013 21:02:23 UTC