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
Support Twitter futures #833
Conversation
49e2221
to
3d1677f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you able to provide some simple tests? Otherwise I could add them if you are busy.
@@ -36,7 +36,7 @@ jobs: | |||
- &scaladoc | |||
stage: microsite | |||
name: "Generate Scaladoc" | |||
script: sbt ++$TRAVIS_SCALA_VERSION coreJVM/doc coreJS/doc interopCatsJVM/doc interopCatsJS/doc interopFutureJVM/doc interopFutureJS/doc interopScalaz7xJVM/doc interopScalaz7xJS/doc interopMonixJVM/doc interopMonixJS/doc interopJavaJVM/doc interopReactiveStreamsJVM/doc | |||
script: sbt ++$TRAVIS_SCALA_VERSION coreJVM/doc coreJS/doc interopCatsJVM/doc interopCatsJS/doc interopFutureJVM/doc interopScalaz7xJVM/doc interopScalaz7xJS/doc interopMonixJVM/doc interopMonixJS/doc interopJavaJVM/doc interopReactiveStreamsJVM/doc interopTwitterJVM/doc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is interopFutureJS/doc
gone by accident or for purpose? WHy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was on purpose, as I think there isn't (wasn't?) such interop atm. I can reintroduce it though.
interopScalaz7xJVM, | ||
interopScalaz7xJS, | ||
interopJavaJVM, | ||
interopReactiveStreamsJVM, | ||
// benchmarks, | ||
interopTwitterJVM, | ||
benchmarks, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was the reason to have benchmarks
commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea. It was commented out for a long time now. As far as I can see it's commented out together with Monix during "death of TF" PR :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember it :D , I wondered why it was already commented before
@LGLO Thanks for the review. I will add the tests. |
@LGLO added docs to sidebar. |
package object twitter { | ||
implicit class TaskObjOps(private val obj: Task.type) extends AnyVal { | ||
final def fromTwitterFuture[A](future: => Future[A]): Task[A] = | ||
Task.effectAsync { cb => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You will also need to handle interruption from the outside with future.raise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any suggestions on the approach? From what I see, interrupt handler is available only for Promise
, and raising is propagated to producers. There are facilities for making it non-interruptible, but I don't think it's the desired behavior :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made some change here
Interruption handler in promise is where you need to accept downstream cancellation, here you need to signal cancellation by using future.raise
.
Besides that fromTwitterFuture
should really accept Task[Future[A]]
(similar to the scala version fromFuture
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @yaroot did 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yaroot fromFuture
doesn't accept Task
, as far as I can see, it accepts ExecutionContext => scala.concurrent.Future[A]
. I'll take a look at the solution you suggested, or, I can retract the PR and let you submit the solution, if it's the preferred approach :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mijicd no worries, I should have been clearer 😅 Yes the Task[Future[_]]
thing is rather hard to find. By name seems fine to me.
Great work 💯
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I wasn't aware of this, sorry @yaroot. That being said, I see there are multiple ways we are "playing" with futures: thunks, by-name, wrapping them in IO... not sure that we need all of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mijicd great work. Yes they're all thunks, but IO has nice properties and easier to reason about (much easier than by-name), not to mention keeping the API in line with existing ones.
In the latest commit (https://github.com/scalaz/scalaz-zio/blob/dbc12eef5809aa34e2eae8b17e13bdcdfd7d42ed/interop-twitter/jvm/src/main/scala/scalaz/zio/interop/twitter.scala#L10-L15) the future is actually evaluated twice, if you change the variable lazy val future = ...
to def future = ...
or inline it like Task.fromTwitterFuture(Future.sleep(..))
the test will be broken, which would be a nightmare to debug in application code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Let's update this one to task then!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
Instead of providing convertors, twitter-interop will be implemented as API-compatible entity backed by ZIO, as its done with scala futures.
This reverts commit e5ce90d1e0e3dfdd610b44c5860779a844f0a900.
d59384f
to
dbc12ee
Compare
@@ -1,3 +1,4 @@ | |||
version = "2.0.0-RC6" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary? It's added by metals, isn't it? If possible I'd move that out of the way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, it is. All hell breaks loose if you remove it :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sad 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me, thank you very much for your contribution! I've not reviewed for some time so I'll let @LGLO give a final 👍
@LGLO @regiskuckaertz in the end I adjusted the interface as suggested above by @yaroot. Take one more look, and hopefully the build will be green (this flaky reactive test is kinda annoying). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Closes #718.