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

RE: A Challenge Problem for Promise Designers

From: Ron Buckton <rbuckton@chronicles.org>
Date: Mon, 29 Apr 2013 20:39:17 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Mark Miller <erights@gmail.com>, David Sheets <kosmo.zb@gmail.com>, "Mark S. Miller" <erights@google.com>, es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, David Bruant <bruant.d@gmail.com>, Dean Tribble <tribble@e-dean.com>
Message-ID: <33D2646B20374248B7CAA8F25919AAFC42762D62@BY2PRD0111MB494.prod.exchangelabs.com>
> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, April 29, 2013 1:20 PM
> To: Ron Buckton
> Cc: Mark Miller; David Sheets; Mark S. Miller; es-discuss; public-script-
> coord@w3.org; David Bruant; Dean Tribble
> Subject: Re: A Challenge Problem for Promise Designers

> > * Added Future.from to perform explicit assimilation (with only one
> > level of unwrap, as with Future#then)
> Like I said, Domenic says that recursive assimilation is useful, and I'm inclined
> to believe him, as he has a lot more experience in getting arbitrary thenables
> to play nicely together than I do. ^_^

I'll tinker with it and run some tests. 
> > * Added Future.isFuture to test for native Futures
> For the purpose of library code, you don't need this - just use "x instanceof
> Future".  Future.isFuture is only useful for the language to define, so that it
> can tell something is a Future cross-frame.

The intent is to eventually have a rough polyfill for ES5 and earlier, so if Future.isFuture becomes part of the spec this would likely match using some kind of pseudo-symbol polyfill. 

> ~TJ

Received on Monday, 29 April 2013 20:40:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC