2.x changing some Observable operators to return Single.

[abersnaze]

I was looking through the Observable operators and wondering if now would be a good time to change the following methods to return Singles instead of Observables.

• Single<Boolean> all(Predicate<? super T> predicate)
• Single<Boolean> any(Predicate<? super T> predicate)
• <U> Single<U> collect(Callable<? extends U> initialValueSupplier, BiConsumer<? super U, ? super T> collector)
• <U> Single<U> collectInto(final U initialValue, BiConsumer<? super U, ? super T> collector)
• Single<Boolean> contains(final Object o)
• Single<Long> count()
• Maybe<T> elementAt(long index)
• Single<T> elementAt(long index, T defaultValue)
• Maybe<T> firstElement()
• Single<T> first(T defaultItem)
• Completable ignoreElements()
• Single<Boolean> isEmpty()
• Maybe<T> lastElement()
• Single<T> last(T defaultItem)
• Maybe<T> reduce(BiFunction<T, T, T> reducer)
• <R> Single<R> reduce(R seed, BiFunction<R, ? super T, R> reducer)
• <R> Single<R> reduceWith(Callable<R> seedSupplier, BiFunction<R, ? super T, R> reducer)
• Maybe<T> singleElement()
• Single<T> single(T defaultItem)
• Single<List<T>> toList()
• Single<List<T>> toList(final int capacityHint)
• <K> Single<Map<K, T>> toMap(final Function<? super T, ? extends K> keySelector)
• <K, V> Single<Map<K, V>> toMap(final Function<? super T, ? extends K> keySelector, final Function<? super T, ? extends V> valueSelector)
• <K> Single<Map<K, Collection<T>>> toMultimap(Function<? super T, ? extends K> keySelector)
• <K, V> Single<Map<K, Collection<V>>> toMultimap(Function<? super T, ? extends K> keySelector, Function<? super T, ? extends V> valueSelector)
• Single<List<T>> toSortedList()
• Single<List<T>> toSortedList(final Comparator<? super T> comparator)
• Single<List<T>> toSortedList(final Comparator<? super T> comparator, int capacityHint)
• Single<List<T>> toSortedList(int capacityHint)

(These were removed from the API:)

• Single<List<T>> takeLastBuffer(int count)
• Single<List<T>> takeLastBuffer(int count, long time, TimeUnit unit)
• Single<List<T>> takeLastBuffer(int count, long time, TimeUnit unit, Scheduler scheduler)
• Single<List<T>> takeLastBuffer(long time, TimeUnit unit)
• Single<List<T>> takeLastBuffer(long time, TimeUnit unit, Scheduler scheduler)

[vanniktech]

I'm +1 for it I also suggested that here for a few operators #4277

[akarnokd]

I don't know, looks like one needs to convert back to Flowable all the time plus one needs to update a large amount of unit tests manually.

[abersnaze]

@akarnokd Why don't the operators on Single return Flowables? Isn't singleSubscribe an implicit request one?

As for the unit tests it's a large task but not insurmountable.

[akarnokd]

Some do, like Single.concat that have to be "widened" but mostly Single stays Single. Plus, Single doesn't have backpressure at all so no request(1) inside it. Reactor's Mono (0, 1, error) is a Publisher so they have to honor backpressure for that maybe 1 element.

[abersnaze]

@akarnokd Yes, I agree Single should not have back pressure because it is fixed size and subscribing can be thought of as an implicit request one. In other words if the subscriber doesn't have enough room in the queue for one element then don't subscribe.

[davidmoten]

I'm a bit nervous about Single not supporting backpressure. We got into trouble with Observable.just(item) not supporting backpressure in 1.x. See
#3044 which includes references to failures.

[LalitMaganti]

I agree with @davidmoten. It was clear that a mistake was made with just ignoring backpressure and it feels like the same mistake is being made again. Plus gaining compatibility with Mono is something which I would much appreciate.

[abersnaze]

The main difference in this case is that Single isn't meant to support back pressure so it wouldn't mix of behavior like there was with just.

[LalitMaganti]

I understand. I just dislike the lack of consistency between the flow control mechanisms on Flowable and Single/Completeable i.e. for Flowable I call request to control flow but I need to hold off on subscription entirely for Single/Completeable.

I do get that Observable relates much better to Single/Completeable than Flowable, but I also feel that backpressure should be a default and only turned off if performance is truly a consideration - i.e. use Flowable until it is known that Observable is truly going to improve performance and transform an Observable to Flowable as soon as possible using one of the flow control mechanisms. (AFAIK the only reason Observable exists is for performance right?).

[JakeWharton]

I don't see Single or Completable missing backpressure being a problem in
this specific case because Observable itself doesn't support it either. I
wouldn't expect the equivalent operators for Flowable to return Single.

On Wed, Aug 10, 2016, 8:44 PM Lalit Maganti notifications@github.com
wrote:

I understand. I just dislike the lack of consistency between the flow
control mechanisms on Flowable and Single/Completeable i.e. for Flowable
I call request to control flow but I need to hold off on subscription
entirely for Single/Completeable.

I do get that Observable relates much better to Single/Completeable than
Flowable, but I also feel that backpressure should be a default and only
turned off if performance is truly a consideration - i.e. use Flowable
until it is known that Observable is truly going to improve performance
and change Observable to Flowable as soon as possible. (AFAIK the only
reason Observable exists is for performance right?).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#4321 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEZfQ-Ml72NNlWwd_snzT3PnRHV9cks5qenB5gaJpZM4JfzIM
.

[LalitMaganti]

It's not necessarily a problem and I guess reworking Single is unfeasible anyway this close to 2.x RC. Just a small gripe I had :)

[akarnokd]

Backpressure is there to avoid buffer bloat with unknown length streams. Single has only one element to get buffered and generally not a problem.

Observable was introduced because some got annoyed with backpressure and want truly unbounded flows no matter the cost. It has lower overhead than with backpressure but generally, the late optimizations to Flowable put them quite close.

Personally, I'd get rid of all but Flowable because it can support all the other behaviors plus I don't have to do 3x the work to keep everybody symmetric in terms of features.

[artem-zinnatullin]

Yeah, even 1.x codebase is quite hard to maintain, 2.x with different Flowable/Observable makes it even harder to work with…

@akarnokd you can add basic support of Single and Consumable in 2.x (basically just make library architecture aware of them from the beginning instead of adding them post-factum as it was in 1.x), non-basic operators can be added by community according to its needs as it happens/happened in 1.x.