- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 2 May 2013 15:24:18 -0700
- To: "Mark S. Miller" <erights@google.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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