We do not wait for the operation to complete before returning the caller gets the power of deciding whether to wait, Returns a Future, which will eventually provide an Employee, or error out. The first two methods do synchronous IO: Whenever we call them, our thread will patiently wait until we get the requested information, leaving our thread blocked. I have an implementation for that trait, but it’s not that important. The futures library lets us specify this using implicit parameters.įor illustration, let’s define some data types and a fake Data Access Object with the following operations:Ĭase class Role(name:String, department :String)Ĭase class EmployeeWithRole(id :Int, name :String, role :Role)ĭef employee(id: Int)( implicit e :ExecutionContext) :Futureĭef role(employee :Employee)( implicit e :ExecutionContext) :Future The gist of it is that a Future contains a value that mayįutures let us spin off work into other threads, add more operations that should be performed on the result,ĭefine what should happen after failure, and (if we really must) wait for the operation to complete.Įverything we do asynchronously happens on some other thread.Ĭreating a future, adding operations after success, adding failure handling – in each case, we need to tell it what thread to run on. Scala Futures use implicit parameters in this way. Implicits as an alternative to passing the same argument over and over.

Now, we’ll take a look at another usage pattern every Scala programmer sees: We looked at implicit parameters and type tags. Implicits are difficult to understand because they have many different uses.

Scala future