I've just incorporated Rx 1 in a solution because we needed .NET 4.0 and just couldn't rely on .NET 4.5 yet, so this is very welcome.

The current F# Rx streaming pipeline abstraction that we use looks like this:

type 'a Signal=
    | ValueSignal of 'a
    | ErrorSignal of Exception
    | StatusSignal of string
    | ProgressSignal of decimal

posted by exoteric

I absolutely love Rx, I think it's the missing LINQ (hehe) in programming today. And people say Microsoft doesnt innovate

In a previous thread I asked why all events could not be replaced with observables, as events are an obvious hack , Bart stated that it would be too expensive because per event we would have an instance of an observable. Loading the .Net framework into memory would then hog too much memory.

I've come up with what I think is a solution.

When currently you raise an event, you create an OnSomeEvent method, wich checks if the actual event is not null and then raises the event. We can do something simular with Rx. Create an private Subject<T> expose it as an property of the type IObservable<T> with only a getter. In the getter do lazy activation if the subject is null. In the OnSomeEvent check if the subject is not null and call an OnNext.

I'm still strugling with time based operations myself. In my PullToRefresh panel, I need some timeout wich is cancellable. I solved it using pattern recognition, but I think a more elegant solution is out there. So can't wait to see what improvements this release has.

Thanks for this Bart, your poster is going above my bed (if my wife let's me)!

Edit; lol @ Atomium on your desk

posted by Maddus Mattus

posted by felix9

I have to think, code, rethink, code, rethink, code, test, rethink, code, just to get the simplest scenario's to work. I feel I'm missing something, some trick, some common approach, maybe some more XML comments on the Rx Extensions methods would be helpfull.

It feels like you have to know Rx inside out to just get started with it, to me that is shamefull because I believe it's one of the most important discoveries of our time (yes, I really really mean that).

posted by Maddus Mattus

posted by bdesmet

posted by Maddus Mattus

C

posted by Charles

posted by Alex

posted by Charles

https://github.com/panesofglass/FSharp.Reactive/blob/master/src/Observable.fs

The nice thing about F# is that you can implement syntax for Rx.

Although I don't quite like that the For and While builder methods use IEnumerable (seq). Because then you end up converting IObservable's to IEnumerable's and then returning new IObservables again.

Maybe you guys have some best practice here as well...

posted by exoteric

@Maddus, @Felix, @Alex, I too thought there was a little bit of content lacking on Rx. The Videos are awesome, but searching blog posts, video etc can be hard work. So, I bit the bullet and wrote the book on it. It is free, check it out @ www.IntroToRx.com. I am still waiting on the eBook generators to give us a good output before we can publish to Kindle etc., but all the content is right there on the site. -@Charles, feel free to plug the book dude, share the love

posted by LeeCampbell

I think there is still a cost of making all events (just a multicast delegate) into subjects (classes with state and behaviour).

I know it's impossible at v4.5 of the .Net framework, but one can still dream right?

And the subjects would be lazy instantiated, so if they are not used, they are not allocated.

posted by Maddus Mattus

Also, i'd like to say that the reason i keep asking about bcl is that i think Rx is a really foundational technology that nearly all apps can use in some form.. Also, i think it would be really great if the rest of the framework could use Rx to a greater extent, exposing observables in more places.

I really think Rx should have language support.. A completley non breaking [i think] way to do it would be to allow any event to be treated as an observable directly. The FromEvent methods are great but the they still provide a slightly higher usage bar than what's optimal imo.

So im not trolling, i just think rx is to awsome to leave out of the framwork

posted by aL3891

posted by Maddus Mattus

ideally, yeah raising events is also a pain, especially if it supposed to be thread safe.. checking if the event is null? whats up with that..

posted by aL3891

The analogy extends to a comparison of advantages and disadvantages between both approaches. For example, objects have a cost that may not be warranted for a lot of simple events (e.g. button clicks). Also, events are well-suited for a code-centric usage (e.g. kicking off a simple action), while observable sequences provide for a data-centric approach (e.g. computing statistics over temporal data).

posted by bdesmet

It still amazes me that a lot of people havent heard about Rx, I continue to teach the developers around me the phylosophy of Rx.

And it's so much more then a abstraction layer over events. You can project it to larger systems aswell. Like SharePoint for instance, all it does is pull, there is not much push going on.

Facebook is more push then pull, that's why I think they are so popular. You get pulled into the thing!

posted by Maddus Mattus

IO<Result> res1 = GetWebserviceRequest();// (or/and FromEventPattern);
var res2 = res1.MuchLinqHere();
var res3 = res2.ObserveOnDispatcher();
var res4 = res3.LessLinqHere();
var d = res4.Subscribe { ... };

The great thing about Rx is that it is much more efficient than normal events: "MuchLinqHere()" don't cause load to the UI thread. I'm happy with that.

"LessLinqHere()" will cause load to UI thread as it is executed there, right? So... In this application there is a lot of code. I try to call ObserveOnDispatcher as late as possible.

It has to be called before the code tries to make a side effect in Linq: e.g. access Application.Current... or UI.

Now, are you saying in the video that in Rx2.0:

1. The ObserveOnDispatcher() will happen automatically before "MuchLinqHere()"? Will I lose performance? 
2. Or will it be called just before Subscribe? (Then will it still throw if there are side effects in Linq?)

posted by Thorium

Long story short: you don't have to change any of your code.

posted by bdesmet

posted by Thorium

posted by hhvdblom

posted by Subito