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

On Thu, May 2, 2013 at 3:39 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> From: Jonas Sicking [jonas@sicking.cc]
>
>> (... lots of really good stuff ...)
>
> I agree with everything you wrote, both in the technical content and in the tone. I appreciate the tone as a counterpoint to the two extreme voices we've heard from so far, and in particular it's great you've given some perspective on the WebApps WG process which I don't think many people in this discussion have. It's also really good that you phrased things as "noodling over the Future API" instead of "we produced a spec, you didn't, so STFU".

:-)

A bit of history that might be worth mentioning. It has happened more
than once to people in this group that others have stepped up and said
"We'll write a spec for X, so you can remove it from your spec", but
then never coming through, leaving the original spec with holes in it.
IIRC this happened both with URL processing as well as charset
encodings. One of them more than once. Hence there is reluctance to
have things removed until the other specs actually exist.

> The issue of whether a way to create promises for promises is an important one, and I fear that if DOMFuture continues to allow it, speculative-TC39-promises will be forced to include recursive implicit thenable assimilation in order to prevent such entities, which have made it into the wild of the web via DOMFutures, from infecting the program.

Yeah. I kind of wish that we simply removed the Future.accept
function. As far as I know no use cases for it has been brought
forward, and it introduces a decent chunk of complexity.

The one use case I've come across is if we create a FunctionFuture
interface to allow for background compilation of large JS bodies, and
if we also convert IndexedDB to use Futures, and if we also enable
storing FunctionFutures in IndexedDB as a way to enable not having to
recompile the JS code for backends that can support storing the
compiled code.

In that scenario having Future.accept would allow IndexedDB to return
the FunctionFuture rather than returning the compiled Function object.
Having to return the Function object could mean that you tie the
operation of reading from the database with the operation of compiling
the JS code which is a problem if you're also doing other operations
against the database that shouldn't be blocked by a lengthy JS
compilation.

But there's a lot of "ifs" and "coulds" in the above. So I think it's
a use-case that's too early to worry about.

> But that aside, the issue of whether to assimilate thenables implicitly or explicitly can be considered separately from DOMFuture's promises-for-promises abilities.

I agree. Though several people seem to feel that the two is connected
somehow. Though I haven't understood why.

> And as for your summary of the original question in this thread, of whether thenable assimilation should be done by the promise implementation: it's a good summary. I do want to add one more thing: thenable assimilation only works if `then` is a function, so it's less dangerous than `__proto__` in that sense. May be small consolation to some, but seems important. Otherwise I will not repeat arguments that have happened elsewhere.

I agree that the type-check does makes a big difference. Though the
fact that "__proto__" is a more obscure name than "then", and is thus
less likely to collide with makes a bit of a difference in the other
direction.

/ Jonas

Received on Thursday, 2 May 2013 23:09:00 UTC