scala/scala-async

Name of the await function

EECOLOR opened this issue · 6 comments

Why did you choose the name await when it does not await a future?

When working with futures one of the first things you learn is to never use Await.result to prevent blocking. I was (before I understood what the async library was doing) very reluctant to use the await function from Scala async. I still have problems using it because other people in my company sometimes mistake it for an Await.result call.

It might be interesting to use another name. Maybe something like resultOf or valueOf.

We had the same discussions during the design process, but in the end decided to stick with the names established by C#. You just have to explain that "lower case await` is safe; but offers the same programming model as the blocking Await.result"

The problem with that is that in tests it is often desirable to wait for a result. This Await.result call gets refactored into an await method with the same signature as your method.

We could of course create an alias for the method, but it would be nice if the library supplied another alias as well.

FWIW I just started using it and I liked async and await because of it's precedence being used in C#.

We actually though of renaming Await.result to Block.block or somesuch, but didn't get around to that.

Atry commented

I don't like the name await. And the { } or ( ) around the origin function call annoys, too.

For example, if you are downloading a page, you may have:

import scala.async.Async._
async {
  val htmlContent = await { downloadUrl("http://xxx.com/index.html") }
  print(htmlContent)
}

The stupid ) } ending let me think of the nightmare Node.js.

And the syntax I prefer is:

async start {
  val htmlContent = async wait downloadUrl("http://xxx.com/index.html")
  print(htmlContent)
}

Where async is the package object scala.async. So the users do not need to import anything.

@retronym Thats probably a smarter idea, the word await doesn't imply blocking, it implies that you are waiting for a result.

Probably adding an alias (which in future would be deprecated) which would be lick Block.result would be a better solution