rx.Future/Task/Async/Single

[benjchristensen]

Explore whether an rx.Future makes sense to allow better representation of Scalar responses.

---

Comment below explaining reasoning: #1594 (comment)

[Matthias247]

I really would love to see this because of 2 reasons:

• There is no good (async & composable) Future type in the Java standard library if you have to target < Java8. Even with CompleteableFuture available this uses executors for the continuations. For an RxJava integration using an Rx Scheduler is a better match - we can then receive Observable events and Future continuations on the same scheduler.
• The alternative is using an AsyncSubject. The problem with AsyncSubject is that the user only sees an Observable in the API and thereby won't know that it emits only a single item. He also won't know if it's hot (the function call which returns the Observable will immediatly start an operation without the need for Subscribe() or not (needs Subscribe()). Therefore I think the ability to model such single return-value async operations with Futures makes an API better understandable.

[headinthebox]

https://github.com/BoltsFramework/Bolts-Java is the java version of .net's task.
Rx.net has seamless integration between observable and task.

However without async await syntax, tasks/futures do not provide much advantage. I don't ever expect async await to be added to java BTW.

[Nilzor]

Rx.net has seamless integration between observable and task.

Yes, but RxJava hasn't. An integration/interfacing with Bolts could be an option instead of separate implementation, but it would probably require som changes to Bolts as well. Bolts, unlike RxJava, rely on Executors.

However without async await syntax, tasks/futures do not provide much advantage

Over what? Observables? Simpler syntax and easier learning curve would be one. Right now I'm using Observables for Scalar data (HTTP responses) because that's the only thing Retrofit supports, but it's been a challenge to sift through the wiki finding just the methods I need for these kind of tasks. continueWith=flatMap? Not intuitive. I simply feel I'm using the wrong tool for the job.

[benjchristensen]

it's been a challenge to sift through the wiki finding just the methods I need for these kind of tasks

The flatMap operator would almost certainly exist on the rx.Future. For example, see the Twitter Future that has flatMap: https://twitter.github.io/util/docs/index.html#com.twitter.util.Future

What makes the use of flatMap not intuitive on an Observable that has a single value versus multiple values?

[Nilzor]

What makes the use of flatMap not intuitive on an Observable that has a single value versus multiple values?

First and foremost the naming. "FlatMap" doesn't tell me anything. What's "unflat" about a Scalar value? What part of the operation involves mapping of any kind? Promise.then is much more descriptive to me.

But I realize it might be my background coming from Tasks in C# to Promises in Javascript and then Observables that might be "polluting my mind". I also might have misunderstood this isse. Maybe you could elaborate, since you're the OP?

[headinthebox]

flatMap in RxJava is selectMany in C#. Since you mention you know Tasks form C# you should read this http://blogs.msdn.com/b/pfxteam/archive/2013/04/03/tasks-monads-and-linq.aspx. Technically speaking the Task API is a so-called co-monad, but since they are continuations, Task can also be formulated as a monad. In Rx .NET we had manySelect for a while that corresponds to continueWith.

[benjchristensen]

What's "unflat" about a Scalar value?

An async continuation that returns another Future needs to be flattened:

aFuture.flatMap(value -> {
   return doWithThatReturnsAnotherFuture(value);
})

In that case the flat part is flattening the returned Future, otherwise you'd end up with a Future<Future<T>> rather than a Future<T>.

What part of the operation involves mapping of any kind

The function can map from T to R however you wish.

Future<R> Future.flatMap(Func1<T, Future<R>> mapper)

If there is no need to flatten then it would be map:

Future<R> Future.map(Func1<T, R> mapper)

If it is purely a side-effect, then the naming is up in the air but in RxJava thus far it is doOn* method names to signal the side-effects, so something like doOnSuccess/doOnError on a scalar Future and just pass the value through:

Future<T> Future.doOnSuccess(Action1<T> sideEffect)
Future<T> Future.doOnError(Action1<Throwable> sideEffect)

[Nilzor]

Ok thanks for taking the time to answer my questions, it made things clearer.

[Matthias247]

I think the issue here is that flatmap is a description what happens in general whereas then or continueWith describe it in a more concrete way for the Future type.
Some time ago I had no experience with FP programming, so flatmap didn't tell me anything. However continueWith is more self-describing so I could understand it and it's easier to discover in an API documentation. I like it. But as I later learned that then/continueWith are equivalent to flatmap so now I understand it too. Maybe the same applies to other users?
Why not expose both function signatures? Don't think it would be a problem and I think it would make the familarity higher for OO as well as FP programmers.

However I thought the more general question was whether RxJava would get a Task/Future like structure at all? I would still like to see it. Bolts looks good, but having a single library for all kinds of asynchronous things and with the possibility for interaction between structures (futures to observables and the other way around, sharing of schedulers, ...) would be even nicer.

[benjchristensen]

However I thought the more general question was whether RxJava would get a Task/Future like structure at all?

Yes, that's the more general question. I tend to think we should.

having a single library for all kinds of asynchronous things and with the possibility for interaction between structures ... would be even nicer.

Agreed, which is why I want it part of RxJava. Most everything would be shared, mostly just the type signature would differ.