Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@khajavi
Copy link
Member

@khajavi khajavi commented Jun 25, 2022

No description provided.

@khajavi khajavi marked this pull request as ready for review June 25, 2022 08:42
> Note:
>
> In ZIO 2.x, the `ZIO#provide` method—together with its variant `ZIO#provideSome`—is a default and easier way of injecting dependencies to the environmental effect. We do not require creating the dependency graph manually, it will be automatically generated. In contrast, the `ZIO#provideLayer`—and its variant `ZIO#provideSomeLayer`—is useful for low-level and custom cases like.
> In ZIO 2.x, the `ZIO#provide` method—and all its variants `ZIO#provideSome`, `ZIO#provideCustom`—is a default and easier way of injecting dependencies to the environmental effect. We do not require creating the dependency graph manually, it will be automatically generated. In contrast, the `ZIO#provideLayer`—and all its variants `ZIO#provideSomeLayer`, `ZIO#provideCustomLayer`—is useful for low-level and custom cases like.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is an unnecessary change. There was another PR that we merged to delete references to provideCustom since it was deleted.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird change! Wondering how it comes to my commits :)
Fixed!


In ZIO 1.x, we used the `zio.Runtime.unsafeRun` method to run a ZIO workflow:

```scala
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to use mdoc on these examples where possible so we test that they compile.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but some of them are based on ZIO 1.x, one of them is just a diff snippet based on ZIO 2.x, some of them are just simplified definitions of the API, and one another is based on scala 3. All of these are not type-safe.

Fortunately, the final snippet has a type-safe mdoc modifier.


For example, if we wanted to integrate a ZIO workflow with a legacy unsafe code, we used to write something like this:

```scala
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to do the migration table for Runtime.unsafe*** here or in a separate PR?

Copy link
Contributor

@adamgfraser adamgfraser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Just a few comments.

@adamgfraser adamgfraser merged commit d919d9c into zio:series/2.x Jun 26, 2022

| | ZIO 1.0 | ZIO 2.x |
|---------|----------------------------|-------------------------------------------------------------|
| Scala 2 | `zio.Runtime.unsafeRun(x)` | `Unsafe.unsafe{ implicit u => zio.Runtime.unsafe.run(x) }` |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@khajavi Would be good to add the other unsafeRun variants from ZIO 1.0 to this table.

@khajavi khajavi deleted the unsafe-marker branch June 28, 2022 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants