jypma opened a new issue, #1801:
URL: https://github.com/apache/pekko/issues/1801
In a pekko Java project I'm working on, I've been creating a `Task` class
whose abstraction looks something like:
```java
public abstract class Task<T> {
public static <T> Task<T> of(Supplier<T> fn) {}
public static <T> Task<T> connect(Source<A, ? extends KillSwitch>
source, Sink<A,CompletionStage<T>> sink) {}
/* ... */
public abstract TaskControl<T> run(Materializer mat);
}
public class TaskControl<T> {
public void cancel() { /* ... */ }
public CompletableFuture<T> future() { /* ... */ }
}
```
`Task` is a description of running something, but also has a unified
cancellation API (across futures and connected `RunnableGraph`s). It is
inspired heavily from ZIO's API. A lot of combinators are written.
Would this be an interesting abstraction to have in Pekko itself? The fact
that streams need to be materialized brings them close to a `Task` monad
already, and in my experience having a unified API between running streams and
futures is very valuable.
We'd of course add a nice Scala API as well (which should be trivial).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org
For additional commands, e-mail: notifications-h...@pekko.apache.org
