W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 2 May 2013 15:32:23 -0700
Message-ID: <CAAWBYDAD7YDqvJLm4Edp56j_hOjWwTeOdH1x7jyRtVDCqUzeqw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "Mark S. Miller" <erights@google.com>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Thu, May 2, 2013 at 3:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> So, with that said, I completely agree with you that recursive
> flattening is neither necessary or possible.

"necessary" and "possible" are two very different things.  If it's not
possible, then you don't need to talk about necessity.

Mark has been arguing that promises should not have a lift operator.
Futures have a lift operator - the Future.accept() static method.  So,
it *is* possible to do recursive flattening, since you can create
nested Futures.  Whether it's necessary or harmful is a question on
its own.

> 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.

Yes, this is what I meant to invoke in my characterization of it as
bad.  Magic properties with distinguished names are bad things which
we should avoid unless there's compat weight we can't fight against
(like __proto__ had).  In the .iterator() case, we're using Symbols
now, which is fine.

> 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.

Yes, this is exactly what I want, including the name (so it matches
Array.from).  (I'd also like Future.accept() to be renamed
Future.of(), also to match Array.of(), but I'd be okay if that didn't
happen. ^_^)

~TJ
Received on Thursday, 2 May 2013 22:33:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC