Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to realize the sequence of Future". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to achieve sequence of Future".

1) the usage scenarios of Option [T], Either [E, R] and Try [T].

These three type are easily reminiscent of scenarios dealing with Exception. These types would be a little narrow if they are only aimed at Exception. Now my feeling is:

1) Option is suitable for dealing with business logically requiring null values, which is not necessarily caused by Exception. It is often the business that needs to express this kind of "empty" / "worthless".

2) the left value of Either is not necessarily Exception, indicating that there may be two better results for a calculation, and the right value conventionally indicates the result under the correct / normal path. The left value is the result of another branch. Of course, you can also put Exception,Error or something. The Response body part of STTP is an Either [Error, T].

3) Try, in fact, is the most suitable type to indicate that an Exception may occur in a calculation. Try's apply () accepts a block of code and runs it, encapsulating the exception into a subclass Failure.

The final feeling is that Option,Either is more like a scalar, a static representation of the result. Try is dynamic and includes the execution of the code. Take a look at the definition of Try and experience:

Object Try {def apply [T] (r: = > T): Try [T] = try Success (r) catch {case NonFatal (e) = > Failure (e)}}

2) realization of Future's sequence ().

1) this is the implementation of Erik's favorite recursive approach.

Two of the flatMap are flatMap on Future.

Def sequence [T] (fts: list [FutureList [T]): FutureList [T]] = {fts match {case Nil = > Future (Nil) case ft::fts = > ft.flatMap (t = > sequence (fts) .flatMap (ts = > Future (t::ts))}}

2) through type derivation, I found that replacing flatMap () with map () also conforms to type checking, which doesn't seem to be a big problem. Logically, however, this implementation has to wait until all the future are complete from the tail in turn. The above implementation of the whole process is asynchronous, more in line with the original intention of Future.

Def sequence [T] (fts: list [ts [T]): FutureList [T]] = {fts match {case Nil = > Future (Nil) case ft::fts = > ft.flatMap (t = > sequence (fts) .map (ts = > t::ts))}}

3) sequence implemented by Erik through async,await.

This approach seems easier to understand, but the style is too FP. Erik warns against wait if you are programming based on Future. Except in async blocks, because async itself is asynchronous, it does not block. In addition, async/await is in the module scala-async and needs to be added to the dependency of sbt.

Import scala.async.Async. {async, await} def sequence [T] (fs: list [FutureList [T]]): FutureList [T] = async {var _ fs = fs val result = ListBuffer [T] () while (_ fs! = Nil) {result + = await {_ fs.head} _ fs = _ fs.tail} result.toList} Thank you for reading. This is the content of "how to realize sequence of Future". After the study of this article, I believe that you have a deeper understanding of how to achieve the sequence of Future, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.