Request For Review of Multi-Observables
Closed this issue · 1 comments
Request For Review of Multi-Observables link to project
@abersnaze and I have been exploring a coding style in Rx where more than one data element could be passed via an observable chain. This coding style would be an alternative to existing functionality where one would use subjects and flatMap to tie together two observables. My goal in writing this was to improve composability by obviating the need to close over state in an imperative style. We have an implementation of a subset of Rx operators for a BiObservable
which can be subscribed to by a BiSubscriber
which takes 2 values by onNext instead of just a single one.
Existing uses:
- Need more than one item in an operator function
- Combining of an observable with an observable that subscribes to the original
Motivating reasons:
- Improve the modularity of Funcs by injecting all inputs
- Improve compatibility with Java 8 closures implementation.
Observable.map(Func1)
can only take a 1 argument closure via Java 8 method references/closures. With amap(Func2)
(provided by BiObservable) existing java methods could be used as arguments without creating - By combining observables in this way, developers (and IDE plugins) could reason about dataflow differently. FlatMap loses context of what operators were applied inside the func. BiObservable operators could apply effects without this loss.
- Avoids some cases of
Func1
instantiation inside a flatmap. SingletonFunc2
s could be used where you would otherwise have to close over state via constructor calls. - Prevent double subscription when combining two observables which are derived from the same source observable.
- Avoiding creation and construction of a Pair class for purposes of
onNext
ing
For instance, when flatMapping an Observable is returned from your function and all operators which resulted in that observable are lost in the context of that function. Static analysis would need to step through the observable returned in order to say anything about the data generated by the topmost observable. BiObservable has operators to apply mutations, reductions, and filters to each operator used on that attached Observable to be declared at the topmost layer of operators. This could enable stronger static analysis where it is used.
Remaining Known Areas for Improvement:
- Only the BiObservable has been implemented. Open questions regarding the TriObservable (and above) include: 1) is maintenance feasible, 2) what operators are necessary for conversion.
- reduce and scan replace the first or second element in a bivalue (per the chosen operator) leaving the /other/ element untouched. This is useful in that one of the inputs is preserved but clearly not always desirable. But it is flexible. There are some api decisions like this left to be made.
- Many operators are yet to be implemented.
- Currently written using java8 closures.
- See/file issues on Github project.
For examples, there is the README and one example of usage in the BiObservableExample.
I will continue development on this external project and welcome feedback. Thanks.
This topic and the project seems to be stale. I'm closing this for now. Discussion can continue on the other issue list.