async/await -> await/async: a simpler, less error-prone async syntax

Bob Myers rtm at gol.com
Mon Dec 4 14:37:33 UTC 2017


It might be useful to consider the `ControlFlow` notion used in writing
selenium tests.
All the steps in a test routine, which appear synchronous, actually
implicitly introduce the equivalent of promise/then structures.
They took this approach because almost all such integration tests are
asynchronous at their core, and they did not want to force people to write
huge sequences of `then` calls.

It turns out that this approach has a number of problems.
As a result, future versions of selenium will no longer support it.
Test writers will be asked to write `await` where needed.

For more information on this, see
https://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/lib/promise.html
https://github.com/SeleniumHQ/selenium/issues/2969
http://www.assertselenium.com/selenium/promise-manager-in-webdriverjs/

--
Bob

On Mon, Dec 4, 2017 at 7:27 PM, T.J. Crowder <
tj.crowder at farsightsoftware.com> wrote:

> On Mon, Dec 4, 2017 at 12:52 PM, Steven Mascaro <subs at voracity.org> wrote:
> > 3. I think the principle "prefer explicit to implicit" argues in
> > *favour* of the proposal (and against the existing syntax).
> > You gave the example:
> >
> > ```js
> > let x = foo();
> > let y = bar();
> > ```
> >
> > Imperative language conventions imply the second statement only
> > executes after the first is fully complete. But if `foo` and
> > `bar` are defined as async functions, the second statement likely
> > starts executing before the *real* work being done in the first
> > statement is complete.
>
> I understand what you're saying there, I just disagree. I said I know the
> **temporal** sequence when looking at that code, and that's what I'm saying
> we should continue to be explicit about when it isn't "this then that"
> without the job yielding and potentially another job being scheduled in the
> meantime. That kind of yield for other work is a big deal and should, in my
> view, be flagged. I get the desire for it to represent the *logical*
> sequence instead without flags, I just think it's too late to do that to
> JavaScript. I keep flirting with the idea of a purely-async or
> async-is-the-assumption language and this is part of why, but I don't see
> retrofitting JavaScript to be that language. Perhaps that's pessimistic of
> me, but when these two functions have completely different temporal
> semantics, I think it's time for a new language:
>
> ```js
> (await () => {
>     foo();
>     bar();
> })();
> (() => {
>     foo();
>     bar();
> })();
> ```
>
> Maybe before the current `async`/`await` were added, but...
>
> > If you're really committed to being explicit, then we should require
> > the coder to specify how they want *every* call to an async function
> > to be handled.
>
> Clearly not, that's just reductio ad absurdum. We have a massively
> well-established "If it's a plain call, it happens in the same job in
> linear sequence" precedent. For me (and we just disagree on this, which is
> fine), if it's going to be a yield back to the queue, it needs signifying.
>
> Those are my $0.02, FWIW. Maybe I'm being old-fashioned. :-)
>
> -- T.J. Crowder
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171204/60d65c14/attachment.html>


More information about the es-discuss mailing list