- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 29 Apr 2013 11:16:08 -0400
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- CC: 'Linked JSON' <public-linked-json@w3.org>
On 04/28/2013 05:01 PM, Markus Lanthaler wrote: > On Sunday, April 28, 2013 9:29 PM, Dave Longley wrote: >> On 04/28/2013 01:35 PM, Markus Lanthaler wrote: >>> That's where we agree. IMO a Future isn't a construct to let you >>> "call a method in the future" but a placeholder for a return >>> value that might not be ready yet when the function returns. >> I'd be just fine with this, but I don't think that's how Futures >> actually work. Rather, they have to be understood differently in order >> to support certain use cases; you're supposed to be able to attach >> handlers, etc. after obtaining the Future (or Promise) object before >> indicating that you want it to run. > Just out of pure curiosity: What use cases require to attach handlers after > obtaining the Future but before indicating to run it? Why is a separate > mechanism to execute/run the Future needed? One example that I've seen some discussion on the mailing list about is related to attaching handlers for progress events. It's unclear if the DOM Futures API will include the ability to attach handlers to a Future for receiving progress events (other Promise APIs do this), but you wouldn't want to miss any events that happen between the time you create the Future and when you attach such a handler. > > > -- > Markus Lanthaler > @markuslanthaler > > > > > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Monday, 29 April 2013 15:15:03 UTC