- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Sun, 28 Apr 2013 15:28:51 -0400
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- CC: Linked JSON <public-linked-json@w3.org>
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. Maybe these are also implementation details, but it seems more obtuse. Anyway, I'm onboard with the idea that a Future could be seen as something (as the DOM spec says) that is ongoing, hasn't begun, or is already done, I'm just not sure how to reconcile that idea with their various uses -- and this may be different for different Future/Promise APIs. We'll just have to see how it gets sorted out and then, as you said, we can "do the right thing". -- Dave Longley CTO Digital Bazaar, Inc.
Received on Sunday, 28 April 2013 19:27:46 UTC