- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Sun, 28 Apr 2013 19:35:14 +0200
- To: "'Dave Longley'" <dlongley@digitalbazaar.com>
- Cc: "'Linked JSON'" <public-linked-json@w3.org>
On Sunday, April 28, 2013 7:11 PM, Dave Longley wrote: > I haven't misunderstood you from the beginning (I don't think). But > none of this addresses my point. Maybe I was misunderstanding you then. > It is all about implementation > details, not the *meaning* of Futures -- and how they relate, > consistently, to an analogy to synchronous programming without being > synchronous at all themselves. If we were to just look at > implementation details without understanding the higher-level > abstraction of what Futures are supposed to *mean*, I would agree with > everything you've said. But there is an emergent property from all of > this; it isn't just about renaming symbols with different names. > > I don't really care how all of this turns out, to be honest, but I > feel as though various arguments made with respect to the way Futures Neither do I really. I just want to make sure we do the right thing. Maybe we should ask some other people for their opinion if we can't come to a conclusion ourselves. > behave (they must be near-perfect analogies to synchronous > programming, etc.) would be inconsistent if we don't think of these > asynchronous operations as actually fully happening in the future, > rather than partially in the present. > > It's like there is a gatekeeper getting in the way of making > asynchronous calls here, that isn't there in the synchronous case. > Here's the difference to the two error-raising approaches: > > Dev: I'd like to be able to call X in the future (with these > parameters). App: Ok. Here's something to let you do that. Now you can > call X later. *Dev attempts to call X* X: Oh, there's a problem. > > vs. > > Dev: I'd like to call X in the future (with these parameters). App: > No, I already know what would happen in the future if you tried to do > that with X, despite the fact that (perhaps) it's not my > responsibility to know that. I won't even allow you to call X and find > out for yourself. I think I now understand why we disagree and where the confusion comes from. IMO the dev wouldn't ask "I'd like to call X in the future". It would just program it as it would be synchronous. He couldn't care less. So he invokes the function thinking with the assumption that it is synchronous. He gets back a return value. Since the value might not be available yet at that point he gets back a Future instead. As soon as he needs to use that return value, his code will block until the value is available. In some languages that's completely transparent. Everything is handled automatically for you. In other languages you either have to request the value explicitly. Since JavaScript is single threaded and can't be blocked without freezing the UI thread, you need to register a callback instead. > As you can see, the root of this problem may be that the parameters > are being leaked due to implementation details. If the thing > responsible for making it possible for me to call a method in the > future wasn't able to see those parameters then this problem would > entirely go away. 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. > It's just an implementation detail (that essentially > presumes closures of some sort will be used) that enables this problem > to even exist. This also reflects the problem that, if X can be called > in more than one way, now both X and a gatekeeper have to know what > conditions make that permissible. > > If you changed the Futures API to work like this: > > Future createFutureFor(asyncOp); > > var foo = createFutureFor(expand); var x = yield foo(input); > > You could see how the constructor "createFutureFor" has nothing to do > with the parameters given to the asynchronous operation. Yeah, but that's not what Futures are. Citing Wikipedia: "In computer science, future, promise, and delay refer to constructs used for synchronizing in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is yet incomplete." http://en.wikipedia.org/wiki/Futures_and_promises Cheers, Markus -- Markus Lanthaler @markuslanthaler
Received on Sunday, 28 April 2013 17:35:48 UTC