add Subscribers.wrap

[davidmoten]

Add utility method to Subscribers to perform this common use case:

Naming briefly discussed in #3057.

new Subscriber<T>(subscriber) {

    @Override
    public void onCompleted() {
        subscriber.onCompleted();
    }

    @Override
    public void onError(Throwable e) {
        subscriber.onError(e);
    }

    @Override
    public void onNext(T t) {
        subscriber.onNext(t);
    }

};

[benjchristensen]

This calls from but it should be wrap.

[davidmoten]

erk, thanks!

[benjchristensen]

I'm trying to remind myself what in these cases we can't just pass the subscriber through if we're not actually changing any behavior. Unsubscription will propagate up and down, so it's not decoupling anything. So why must we allocate and wrap in these use cases?

[davidmoten]

Double call of onStart was one reason.

On Tue, 14 Jul 2015 07:08 Ben Christensen [email protected] wrote:

I'm trying to remind myself what in these cases we can't just pass the
subscriber through if we're not actually changing any behavior.
Unsubscription will propagate up and down, so it's not decoupling anything.
So why must we allocate and wrap in these use cases?

—
Reply to this email directly or view it on GitHub
#3065 (comment).

[davidmoten]

used wrap instead of from in OnSubscribeUsing and rebased.

[benjchristensen]

Double call of onStart was one reason.

Ah right. So wrap is really about when we need to decouple or handle nested subscribes.

[benjchristensen]

This one is less obvious as to why it needs to be wrapped. The duplicate onStart problem seems like something we should fix inside Subscriber rather than needing to object allocate and wrap.