Reactive Overloads for Static Parameters

[dotnet]

Reactive Overloads for Static Parameters

[mattpodwysocki]

I'm thinking now that Rxx's WindowIntrospective operator may in fact be another "dynamic" variant of ObserveOn. Although the scheduler doesn't vary, the size of the internal queue does.

See also: https://rx.codeplex.com/workitem/82

[RxDave]

More details:
http://davesexton.com/blog/post/Reactive-Reactive-Read-all-about-it.aspx

[headinthebox]

Yup, obviously missing when we went through the operators.

[akarnokd]

I'm wondering how can you reasonably change, for example, the limit in Take while it is running? I.e., you start out with a signal of 5, then change your mind and singal 3 as the limit. Now the source produces three items and stops when you are about to signal 7 as the new take limit...

The second problem is that the parameter signals may not be reusable and/or a single hot parameter source affects all Observers of the same assembled chain:

BehaviorSubject<int> takeLimit = new BehaviorSubject<int>();
Observable<int> o = Range(1, 10).Delay(TimeSpan.ofSeconds(1)).Take(takeLimit);

takeLimit.OnNext(5);
o.Subscribe(e => { });

takeLimit.OnNext(10); // will update the previous one's limit as well
o.Subscribe(e => { });

takeLimit.OnNext(1); // this too
o.Subscribe(e => { });

There is already a way of dynamically taking some items: TakeUntil (and TakeWhile if you have that).

[RxDave]

TakeUntil is the dynamic version of Take. I go into a bit more detail in my blog post linked above.

[mattpodwysocki]

@RxDave correct, just as SkipUntil is a dynamic version of Skip. So which operators should we consider here? The entire list? Note that we should backport RetryWhen and RepeatWhen from RxJava and RxJS to Rx .NET. @headinthebox thoughts?

[RxDave]

@mattpodwysocki It's tough to say which would actually be useful without scenarios in mind. Merge has a real-world scenario, so I'd say that's the most important one that I can think of.

#48

Perhaps the heuristic should be to choose those operators that are stateful and will cause an irreversible loss of state when its arguments must change; e.g., when using Switch to re-apply the operator with new arguments. Or at least, if avoiding state loss results in user code that solves the original problem that the operator was intended to solve in the first place, such as trying to dynamically adjust a Take or Skip query without the use of TakeUntil or SkipUntil, respectively.

[RxDave]

Note that I generated that list of operators by simply looking for operators with scalar parameters. I didn't actually pay attention to the semantics or usefulness of such dynamic operators. It's possible that most of those operators wouldn't make much sense as dynamic operators. For example, I'm not so sure that ObserveOn<T>(this IO<T>, IO<IScheduler>> makes sense. Worth considering though?

[akarnokd]

Doesn't make sense to me after these years.

[danielcweber]

Definitely nice to have but I have rarely felt the need, in most cases you can do pretty well with some Publish, WithLatestFrom and Switch although this is not optimal.

[RxDave]

I agree it's rarely needed, but when it's needed it's actually necessary.

Reactive-Extensions#48

The problem is with any operators that may capture state, and whereby resubscribing loses that state. The current workarounds, perhaps, require us to redundantly implement the behavior of a problematic operator ourselves, defeating the entire purpose of the operator in the first place.

Operators that accept observables as arguments, especially only for some parameters, are immediately suspect.

[akarnokd]

Closing due to inactivity.

Still doesn't make sense to me after these years and doubt they can be implemented and used in a reasonable way. Not to mention, the explosion of the API surface.