I have the following code in VB.NET that reads measurements from a laser until a workpiece has been rotated 480 degrees. All in all a very nice application of CTP and RX together.
Dim measurementsList = Await machine.
Measurements.
TakeUntil(machine.Driver.RotateC(480, 10).ToObservable()).
ToList()
Note machine.Measurements is IObservable(of double) in this case and are readings from a laser measuring device on a network.
However I was considering adding an extension method to IObserverable ( Now C# code )
public static IObservable<T> TakeUntil<T,R>(this IObservable<T> This, Task<R> other){
return This.TakeUntil(other.ToObservable());
}
It's really not a big deal and would enable me to write my code as
Dim measurementsList = Await machine.
Measurements.
TakeUntil(machine.Driver.RotateC(480, 10)).
ToList()
which seems more fluent but given that RX does not provide such an obvious overload perhapps I am missing the obvious reason such an overload is a bad idea. Should I add this or stick with the explicit conversion?
(btw should not the tags async-ctp and async-await be merged)
There's nothing wrong with what you are doing, but I'd review Rx v2.0 and .NET 4.5 “async” / “await” – a better together story, from the lengthy and informative post by Bart De Smet.
You may also want to check out Linq-to-Await to see how things are done there. In fact, if you look at the few operators, you'll see that your method is quite similar, except in your case you are taking just a Task, where in Paul Betts Linq-To-Await, he uses Func<T, Task<R>>
. In which case your code could look like this (with a Func with no parameters):
public static IObservable<T> TakeUntil<T,R>(this IObservable<T> This, Func<Task<R>> other){
return This.TakeUntil(other().ToObservable());
}
var q = Measurements.TakeUntil(async () => await machine.Driver.RotateC(480, 10));