2.x: Remove/Hide Flowable BackpressureMode.NONE?

[artem-zinnatullin]

So, we have Observable for nbp streams and Flowable for bp streams.

What I'm afraid of is that a lot of users will do Flowable.create(emitter, BackpressureMode.NONE) or toFlowable(BackpressureMode.NONE) while in fact they should use Observable.

The only correct usage of BackpressureMode.NONE I see at the moment is RS interop since Observable is not RS type (please share other valid cases that can't be changed to Observable).

I might be overworrying of course, so opinions of project members are very appreciated.

[akarnokd]

The NONE can be used if you use onBackpressureBuffer(int capacity) or other parametrized onBackpressureXXX method. The default enums only support the parameterless behavior of onBackpressureXXXs.

[akarnokd]

        /**
         * OnNext events are written without any buffering or dropping.
         * Downstream has to deal with any overflow.
         * <p>Useful when one applies one of the custom-parameter onBackpressureXXX operators.
         */
        NONE,

[artem-zinnatullin]

Yeah I see, hm. But isn't it kind of weird to create Flowable with no
backpressure strategy and apply afterwards If you can accept it from client
and use it at creation time?

On 29 Sep 2016 5:12 pm, "David Karnok" notifications@github.com wrote:

    /**
     * OnNext events are written without any buffering or dropping.
     * Downstream has to deal with any overflow.
     * <p>Useful when one applies one of the custom-parameter onBackpressureXXX operators.
     */
    NONE,

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

[artem-zinnatullin]

So, what should we do about it?

I still think that it's kind of weird to have such easily-available API that can and probably will be misused pretty often and as a result will lead to MissingBackpressureException though one of the ideas of Flowable was to move Backpressure to type level and force users to handle it while BackpressureMode.NONE basically disables that.

Closest semantic problem I can think of is Observable.create() in RxJava v1 which was misused so often that we had to "deprecate" it.

The NONE can be used if you use onBackpressureBuffer(int capacity) or other parametrized onBackpressureXXX method. The default enums only support the parameterless behavior of onBackpressureXXXs.

@akarnokd what if we add APIs to apply parametrized onBackpressureXXX() at creation time?

cc @JakeWharton, we've discussed that offline a little bit and I would like to invite you to discussion here.

[akarnokd]

what if we add APIs to apply parametrized onBackpressureXXX() at creation time?

Either you supply a varargs of options or introduce 8+ overloads.

I still think that it's kind of weird to have such easily-available API that can and probably will be misused pretty often.

Here, the user puts in the mode parameter and is explicit. So if someone reports a MissingBackpressureException and posts a create(..., NONE), that's a clear indication of the user error.

[artem-zinnatullin]

Here, the user puts in the mode parameter and is explicit. So if someone reports a MissingBackpressureException and posts a create(..., NONE), that's a clear indication of the user error.

Yes, but I'm not sure that a lot of users will understand that BackpressureMode.NONE basically == MissingBackpresssureException.

And even worse that when you use already created Flowable you can't be sure that it handles backpressure which basically == situation with Observable in RxJava v1.

[akarnokd]

Lot of users copy from examples and so far, almost all 2.x create examples used BackpressureMode.BUFFER.

you can't be sure that it handles backpressure

If you wrote the create(), then it's on you. If you get a Flowable somewhere and fails, you can check the source code of the provider and apply the missing operator. If no source available, complain to the developer who created it.

[artem-zinnatullin]

Can't completely agree. Ok, what about renaming BackpressureMode.NONE to something that mentions consequences of its usage? I'm bad at naming: UNSAFE_NONE, etc.

[akarnokd]

If you find a good name...

[artem-zinnatullin]

Variants from my team: MISSING, UNSAFE_NONE, TODO, UP_TO_DOWNSTREAM.

I really like MISSING because it matches MissingBackpressureException.

[JakeWharton]

UNSUPPORTED

On Wed, Oct 5, 2016, 7:05 AM Artem Zinnatullin notifications@github.com
wrote:

Variants from my team: MISSING, UNSAFE_NONE, TODO, UP_TO_DOWNSTREAM.

I really like MISSING because it matches MissingBackpressureException.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#4643 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEdIQi457CIe4MgVtVPAnoO9wJYjLks5qw4SMgaJpZM4KKej9
.

[akarnokd]

Alright, MISSING is compact enough. PR welcome.

[akarnokd]

Closing via #4767