RE: JSON-LD API w/DOM Futures implemented

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