- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 1 May 2013 08:21:33 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Domenic Denicola <domenic@domenicdenicola.com>, es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, May 1, 2013 at 12:16 AM, Jonas Sicking <jonas@sicking.cc> wrote: > However with this approach you get an API which automatically simply > works as an API returning a Future in case you don't need to abort the > operation or display its progress: > > handleResult(doSomeOperation()); > or > return doSomeOperation(); > or > doSomeOperation().then(val => displayResult(val)); > > I.e. if you don't care about the operation part, the API simply works > as any other API which returns a promise. This seems like a very nice > thing. The only "cost" of this API is that it doesn't compose when you > compose the future, but neither does the dispose object in the tuple > approach. The other cost is an inherent capability leak - *unless* you purposely strip it of its cancelability, passing it around to anything else gives the "anything else" the ability to cancel your promise as well. The tuple approach doesn't have this issue - the promise and the canceler/resolver are inherently separated, and you have to purposely hand the canceler/resolver off to other code for it to have any powers. ~TJ
Received on Wednesday, 1 May 2013 15:22:21 UTC