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 < [email protected]> wrote: > On Mon, Dec 4, 2017 at 12:52 PM, Steven Mascaro <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
