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

Question: Wrap an async operation (e.g. java.util.Future) inside of an Either? #71

Closed
SkylerLutz opened this issue Aug 9, 2019 · 3 comments
Assignees
Labels

Comments

@SkylerLutz
Copy link
Contributor

SkylerLutz commented Aug 9, 2019

Is it possible to convert an async operation (e.g. fetch records from a database and wrap in a future) to an Either or a Maybe?
If not, is it on the roadmap? Why or why not?
I discovered IO.externallyManaged() but it requires me to invoke Future.get() on my future. I am looking for a way to use the palatable/lambda API exclusively to invoke my async calls.

Thanks

@jnape jnape added the question label Aug 9, 2019
@jnape jnape self-assigned this Aug 9, 2019
@jnape
Copy link
Member

jnape commented Aug 9, 2019

Hi Skyler,

Are you talking about something like this?

Either<Throwable, A> either = Try.trying(myFuture::get).toEither(); // or .toMaybe()

If so, in general I would avoid that, since the Future almost certainly represents a side-effect, and I tend to keep impure operations separate from pure operations. In this case, I would lift the Future into an IO:

IO<Either<Throwable, A>> io = io(myFuture::get).safe(); // or .fmap(Either::toMaybe)

Now, this is about the best you can do if all you have is a Future. Future is a miserable type precisely because it offers no interface for composition or callbacks, which severely limits what can be done with it that doesn't require a call to Future#get.

However, if you had a CompletableFuture, I can lift that into an IO directly via the mechanism that you've already discovered, IO#externallyManaged.

Once you're in IO, you should have no trouble at all wrapping the result in an Either, or a Maybe, or whatever you choose.

So, is the challenge that you just have a Future, and not a CompletableFuture, and you also don't want to call Future#get? If so, I have personally gone to great lengths in the past to proxy Future with CompletableFuture at the expense of a single JVM thread acting as an event loop or selector (think of it as epoll for futures) that connects CompletableFutures to their proxied Future, and I can explain how that worked if you're interested, but that code is not in lambda, and I probably wouldn't put it in lambda since it would require lambda taking one of your threads away from you at start up time.

@jnape
Copy link
Member

jnape commented Aug 9, 2019

If you'd like to discuss this in real time, if that's easier, please join me in the lambda gitter and we can chat about this: https://gitter.im/palatable/lambda

@jnape
Copy link
Member

jnape commented Aug 12, 2019

Continuing this conversation on the gitter channel, so closing.

@jnape jnape closed this as completed Aug 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants