[Idea] Handles supports for IObservables / IObserver. about vblang

[AnthonyDGreen]

Interesting. Could you update your example to something more real? I'm curious to see how it would work with different handlers for different layers of the stream (if that makes sense). Or is it that the handler just handles the tail end of the stream and doesn't do any filtering or manipulation to parts prior?

[AdamSpeight2008]

My understanding of Observable, that this would fired every time the Observable "Pushed" a new value onto OnNext.

dim _HeartBeat  = Observable.Interval(TimeSpan.FromSeconds(1))
Function HeartBeat(x As Long) Handles _HeartBeat.OnNext
   ' Triggered every ~second
End Function

Think this needs a lot more bake time.

[HaloFour]

You can already do the following with Rx.NET:

Dim o = Observable.Interval(TimeSpan.FromSeconds(2))
o.Subscribe(Sub(ByVal value As Long)
                ' triggered every second
            End Sub)

For language integration I'd personally rather see asynchronous enumerators in async methods, something like:

Dim o = Observable.Interval(TimeSpan.FromSeconds(2))
For Each Await value In o
    ' triggered every second
Next

[AdamSpeight2008]

@HaloFour The Idea was to be able to treat them as an event-like object.

[AnthonyDGreen]

I kinda think of IAsyncEnumerable and the Await Each loop to be foregone conclusions at this point :)

I'm pretty hesitant on Rx. Can you point me to a killer sample app on it that really highlights why people love it?

[HaloFour]

I'm pretty hesitant on Rx. Can you point me to a killer sample app on it that really highlights why people love it?

From what I gather most people don't seem to understand it. It's simply nothing more than the combination of events and LINQ. If you needed to do anything complicated with a stream of push-based notifications (which all user-interface interactions are), then it's a lot easier to feed that through a LINQ query rather than subscribing to a bunch of events disparately and maintaining a state machine full of variables in order to detect when the right combination of things has happened.

But yes, I do understand that the language teams are largely settled on the IAsyncEnumerable<T> concept, which is effectively the same except it requires that the consumer continually request the next value. That's not unlike the Rx concept of backbuffer where the consumer can inform the producer how many values that it is ready to accept, only that the consumer can only request one at a time. That model will be considerably slower for streams processing.

Fortunately bridging Rx and IAsyncEnumerable should be pretty easy. In fact if async enumeration supports extension methods to resolve GetAsyncEnumerator then the above code could work out of the box. That bridge could allow the consumer to configure such things as over-subscription via buffer of events or the like.

I find it funny and sad that Rx is being adopted more readily outside of the .NET world. Netflix completely rewrote it for Java and has based quite a few of their libraries on it, including Hystrix which I use extensively for bulk-heading and fault tolerance. I'm currently using RxJava to work on an asynchronous JSON parsing and data-binding engine which I can feed from an NIO loop so that I can shred through massive JSON documents with virtually no memory overhead and without blocking.