2.x: Maybe for lazy Optional

[abersnaze]

In #4321 I hit on the problem of needing a lazy object that could either be zero or one value. In that issue the idea of switching the return value of reduce(R, Func2<R,T,R>) from Observable<R> to Single<R> because that operator can only ever produce an Observable that emits exactly one value. The problem was that reduce(Func2<T,T,T>) could not be changed to Single<T> because the source Observable could be empty and therefore not produce one and only one value.

To solve this problem I mentioned we could create a lazy type that represents either 1 or no value could fill the gap between Completable and Single<T>.

This PR is for the introduction of the Maybe<T> type.

[akarnokd]

Why are these misaligned?

[akarnokd]

You referenced Java 8 types in your code.

[akarnokd]

My problem with adding another base type is the increased maintenance cost. Currently we have 3 + 4 types in the major versions and it is likely adding a new operator, overload or making a fix has to be done for all of them. I'm one-man armying RxJava for a considerable time now but I have my limits. Therefore my suggestion is that you have this Maybe as a separate library that depends on RxJava 2 but RxJava 2 doesn't depend on it. Since RxJava 2 offers fluent conversion method(s), it should be only a small inconvenience to convert to Maybe:

Flowable<Integer> source = Flowable.range(1, 10);

Maybe<Integer> mb = source.to(Maybe.reduceFlowable((a, b) -> a + b));

mb.filter(v -> false).subscribe(
    System.out::println, Throwable::printStackTrace, () -> System.out.println("Done"));

mb.toFlowable().subscribe(
    System.out::println, Throwable::printStackTrace, () -> System.out.println("Done"));

[abersnaze]

As I mentioned my plans were to greatly increase the coupling between Observable & Flowable to Single & Maybe by having the various operators that return exactly 1 or sometimes 1 value to these two types.

[codecov-io]

Current coverage is 71.96% (diff: 0.07%)

Merging #4436 into 2.x will decrease coverage by 3.14%

@@                2.x      #4436   diff @@
==========================================
  Files           453        499     +46   
  Lines         32399      33691   +1292   
  Methods           0          0           
  Messages          0          0           
  Branches       5216       5299     +83   
==========================================
- Hits          24336      24246     -90   
- Misses         6034       7431   +1397   
+ Partials       2029       2014     -15   

Powered by Codecov. Last update f97c50d...118f21a

[akarnokd]

I'm willing to accept Maybe as the 5th reactive type but the class needs javadoc and unit tests that verify the most basic behavior of each operator in it.

/cc @artem-zinnatullin @JakeWharton @zsxwing

[akarnokd]

How about you just contribute Maybe with operators throwing UnsupportedOperationException and I'll add optimized implementations and tests for them as I go?

[akarnokd]

Also Reactor has the Mono type exactly for this purpose, I suggest you try that first.

[JakeWharton]

I'm not strictly opposed because

my plans were to greatly increase the coupling between Observable & Flowable to Single & Maybe by having the various operators that return exactly 1 or sometimes 1 value to these two types.

appeals to me, but I don't have a really strong feeling without using it more.

[akarnokd]

Okay then, let's merge this and see how it works out.

[akarnokd]

Please don't post PRs targeting Maybe - I'm working on cleaning it up a bit (plus a few other classes if I find something wrong); the code copied from an older commit of the other types.