On Fri, Feb 24, 2017 at 6:35 PM, Šime Vidas <sime.vi...@gmail.com> wrote:
> Domenic's version using current `async`/`await` syntax is nice and clear >> (one might tweak the variable names a bit to differentiate promises from >> resolved values, but...). >> > > This is the issue I have with this approach. The author is forced to > create two sets of variables (for promises and resolved values), depending > on the structure of the concurrent tasks. I think this is micromanagement. > Controlling the temporal mechanics of my functions seems pretty macro to me. :-) We just appear to have different perspectives on it, which is fair enough. > Separately, I think you're going to run into implementational complexity. >> [snip] >> > > I’m not sure why it would need to be that complicated. [snip] > That would be simpler, yes, some kind of flag on the binding in the lexical env object perhaps. It would also be a lot less powerful (though I suppose if you need power, keep the promise). It seems like it would encourage people to prefer large functions to small ones working together, though, so they can avoid passing the hidden promise into/out of a call, triggering the hidden `await`. Which, again, you could address by keeping the promise and passing it around instead, but then that negates the utility you're suggesting (not managing the process directly). And programmers don't need more inducement to bad habits. (I'm particularly guilty of this particular bad habit. But I'm trying...) I'm also troubled by how this moves the exception point if the promise rejects, from the nice clear `await` expression to when the side-effect of use occurs. I suppose that's part of my overall concern about hidden behaviors, though. In case it’s not clear, this wouldn’t change how await works or be a > replacement of it. > Just for the avoidance of doubt: You mean it wouldn't be `await`, but something `await`-like but distinct, right? `autoawait`, `await*`, `lateawait`, `jitawait`, something. Again, I find it a really interesting idea, perhaps as a foundational concept for a massively-async language. I'm just not sure about it for JavaScript. Anyway, those are my thoughts, FWIW. I'll lurk for a bit. :-) -- T.J.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
