Rxjava: 2.x: New base interface types

[akarnokd]

As part of the 2.x design, new base interface types have been recently merged & applied. The aim is to match the style of the Reactive-Streams base types + their fluent base class:

Flowable -> Publisher -> Subscriber
Observable -> ObservableConsumable -> Observer
Single -> SingleConsumable -> SingleSubscriber
Completable -> CompletableConsumable -> CompletableSubscriber

They feel odd to me too so any idea is welcome.

[JakeWharton]

Just to be clear before I start thinking about this more, Publisher and Subscriber are the only RS types here, right? And Single and Completable are always backpressure-aware types?

[akarnokd]

Publisher and Subscriber are the only RS types

Yes.

Single and Completable are always backpressure-aware types?

The other base types (including Observable) don't have a notion for backpressure.

[artem-zinnatullin]

Can we please keep names for Observable, Single and Completable since they're not part of RS? They're short and well known.

I'd just rename Observer to ObservableSubscriber to have same pattern as SingleSubscriber and CompletableSubscriber and not interfere with Publisher -> Subscriber.

[JakeWharton]

I wouldn't mind renaming Observable since it's a description of the pattern to which all these types conform. It's the least descriptive of the bunch, and you wouldn't chose it today given the others.

I used to like Flowable, and I still do, but now that we have a non-BP vs. BP distinction perhaps we should consider making BP-aware variants of all 3 types and using Flowable as an adjective instead of a noun? The problem is that gets verbose.

[akarnokd]

Single and Completable don't need backpressure because they emit 1 or 0 items respectively.

The non-backpressured Observable was requested to allow pure GUI event handling where the sources are hot and can't be backpressured.

[JakeWharton]

Hmm what about the request(0) case though? Where work isn't triggered upon subscription but deferred until explicitly requested.

[JakeWharton]

Sorry I mean the case where an operation cannot respect request(0). I'm struggling to come up with an example, but I know I've ran into potential cases before but I never wrote them down (because we never had Flowable either).

[akarnokd]

The current rule of thumb is that if an operator can't respect the request amount, it will signal a MissingBackpressureException instead of overflowing the downstream. This behavior still requires request tracking. The reason for signalling is due to the confusion about the situation in 1.x where exception is signalled in the operator that suffered the buffer overflow attempt and no indication whose fault it was really.

[JakeWharton]

There's also the Subject and FlowProcessor types in the mix here.

[JakeWharton]

I made a chart of the current naming:

And here's my proposal for normalization:

The changes from current master are highlighted.

[akarnokd]

:+1:

[vanniktech]

I'll give the Single changes a try.

[vanniktech]

Will continue with Completable once the other 2 PRs are merged to avoid merge conflicts.

[vanniktech]

The proposed new names have been applied and I guess this issue can be closed then if there is no further input.

[akarnokd]

Renames and refactorings happened.