Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update guide #1068

Merged
merged 2 commits into from Jan 10, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
5 changes: 3 additions & 2 deletions docs/migration-guide-0.10.md
Expand Up @@ -22,7 +22,7 @@ As a result of this migration, the `fs2.util` package has been removed. The type
|`fs2.util.Effect`|`cats.effect.Effect`|
|`fs2.util.UF1`|`cats.~>`|

Note that cats-effect divides effect functionality up in to type classes a little differently than FS2 0.9. The `cats.effect.Async` type class describes a type constructor that supports the `async` constructor whereas `fs2.util.Async` included concurrency behavior. The type classes in cats-effect purposefully do not provide any means for concurrency. FS2 layers concurrency on top of `cats.effect.Effect` using the same `Ref` based scheme used in 0.9, but defined polymorphically for any `Effect`. This functionality is provided by `fs2.async.ref` and other methods in the `async` package. As a result, most implicit usages of `fs2.util.Async` should be replaced with `cats.effect.Effect` and `scala.concurrent.ExecutionContext`.
Note that cats-effect divides effect functionality up in to type classes a little differently than FS2 0.9. The `cats.effect.Async` type class describes a type constructor that supports the `async` constructor whereas `fs2.util.Async` included concurrency behavior. The type classes in cats-effect purposefully do not provide any means for concurrency. FS2 layers concurrency on top of `cats.effect.Effect` using a `Ref` + `Promise` scheme similar to the one used in 0.9, but defined polymorphically for any `Effect`. This functionality is provided by `fs2.async.refOf`, `fs2.async.promise` and other methods in the `async` package. As a result, most implicit usages of `fs2.util.Async` should be replaced with `cats.effect.Effect` and `scala.concurrent.ExecutionContext`.

#### Task/IO

Expand All @@ -43,7 +43,7 @@ As a result `fs2.Task` has been removed. Porting from `Task` to `IO` is relative
|`t.unsafeRunAsync(cb)`|`io.unsafeRunAsync(cb)`| |
|`t.unsafeRunFor(limit)`|`io.unsafeRunTimed(limit)`| |
|`t.unsafeRunAsyncFuture`|`io.unsafeToFuture`| |
|`Task.fromFuture(Future { ... })`|`IO.fromFuture(Eval.always(Future { ... }))`| Laziness is explicit via use of `cats.Eval` |
|`Task.fromFuture(Future { ... })`|`IO.fromFuture(IO(Future { ... }))`| Effect capture is explicit via use of the inner `cats.effect.IO` |
|`Task.async(reg => ...)`|`IO.async(reg => ...)`|Note that `IO.async` does *NOT* thread-shift, unlike `Task.async`. Use `IO.shift` as appropriate (`IO.async` is semantically equivalent to `Task.unforkedAsync`)|

### Performance
Expand Down Expand Up @@ -133,6 +133,7 @@ The `debounce` pipe has moved to the `Scheduler` class also. As a result, FS2 no
The `fs2.time.{ duration, every }` methods have been moved to `Stream` as they have no dependency on scheduling.

#### Merging
TODO: obsolete now (fixed)? We could just say that `concurrently` covers this use case conveniently

The semantics of merging a drained stream with another stream have changed. In 0.9, it was generally safe to do things like:

Expand Down