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

Skip to content

Conversation

@politrons
Copy link
Contributor

I don't know if this operator it has any sense in the ZIO ecosystem, I know we can achieve the same goal of lazy evaluation of futures using fibers. But maybe is not a bad alternative, to provide an operator just like fromFuture, but fromPromise as inter-opt operator for those scala developers, that want to use promises for lazy evaluation of futures.

Description:

Imports a [[scala.concurrent.Promise[A]] an input value of B and a function to apply in [complete] function of promise.
We complete the promise in another thread avoiding blocking the function execution, and in the main thread we generate a future from promise, and we pass to [fromFuture] to transform into ZIO[Any, Throwable, A].

With this operator we allow use Scala promise to have a lazy evaluation of the logic that it will be executed in another thread only when the whole program is evaluated.

@politrons
Copy link
Contributor Author

In this PR there're also some code from a previous PR (#4163) that is pending to being merged once @adamgfraser approve it

@adamgfraser
Copy link
Contributor

@politrons Can't the use case of lazy evaluation be addressed by ZIO.effect(func(input))? ZIO.effect and ZIO.effectTotal are both lazy so you can wrap a computation in them and that computation won't be evaluated until the program is executed by the ZIO runtime.

If we want something just for interop I think we would want it to just take a Promise and it to be the responsibility of the caller to complete that Promise themselves separately. Take a look at fromPromiseJS for an example of that. Maybe we could have something similar like fromPromiseScala since we also want to make clear that this is referring to a Scala promise and not ZIO's own promise.

@politrons
Copy link
Contributor Author

@adamgfraser Hi again,

If I understand your comment, I just extract the logic of execution and completing the promise out of the operator. So basically we just extract the future from the promise.

Not sure to be honest if now this is a useful operator.

* Imports a [[scala.concurrent.Promise]] we generate a future from promise,
* and we pass to [fromFuture] to transform into ZIO[Any, Throwable, A]
*/
def fromPromiseScala[A, B](promise: scala.concurrent.Promise[A]): ZIO[Any, Throwable, A] =
Copy link
Contributor

Choose a reason for hiding this comment

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

You can drop the B type parameter here and return a Task[A].

@adamgfraser
Copy link
Contributor

@politrons Hey! 😃

Yes I think so. That gives the caller the flexibility to complete the promise where they want to. If this is being used for interoperability the code that completes the promise may be impure and in another part of the application where it may not be possible to just import it into the ZIO runtime.

@adamgfraser
Copy link
Contributor

Can you merge upstream changes?

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.

We still need to delete the old tests from StackTracesSpec, right? Otherwise looks great!

@politrons
Copy link
Contributor Author

@adamgfraser I already delete those test when I moved to ZIOSpec

@adamgfraser
Copy link
Contributor

@politrons Looks like the ones from when we added getOrFailOption are still there unless I am looking at the wrong version?

@politrons
Copy link
Contributor Author

@adamgfraser I made in this commit ee7d8f4

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.

Thanks for adding this!

@adamgfraser adamgfraser merged commit 7f1664e into zio:master Aug 31, 2020
@politrons
Copy link
Contributor Author

you welcome, thanks again for the support

@politrons politrons deleted the ZIO_Promise_operator branch August 31, 2020 21:41
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