posted by Eddie Korbs

posted by Waldemar

posted by felix9

Though, it would be better not need to use Reflection, and have it 

So you could write  TextBox. and have Intellisense list some of the possible events.

In my opinion having encode the event name in a string, could lead to problems.

Suppose I mistype the name, I don't get a compile-time warning but a runtime exception.

posted by AdamSpeight2008

http://bit.ly/bfzKCk

C

posted by Charles

Since I like to do all demos live and always avoid to import code snippets on stage (sure, I could build the entire Windows kernel live on stage by dragging and dropping a code snipet of a few million lines of code, that would be immediately obvious to the audience ), I went for the shorter one. Following this approach of live coding allows the brainwaves of the audience to be in sync with mine while producing the code.

That said, this overload is there as the closest one to being able to pass in an event. However, .NET events are merely metadata citizens and are not first-class constructs: in other words, you can't grab them nor pass them around (as opposed to methods which you can grab by means of delegate types).

Hope this helps and thanks for watching,
-Bart

posted by bdesmet

So yes, this was a little bit of jumping around on stage, which is good for my "calories burned count" anyway. Luckily some conference venues provide this kind of equipment .

posted by bdesmet

posted by felix9

In fact, WPF events are not strictly more first class than .NET events, because you still have to pass two pieces of information around: the event object and the instance to which it applies. That's different with delegates, which can capture both the target method and the instance to go with it (remember all the function pointer "fun" in native C/C++ land to achieve a similar effect?).

Having said all of this, again: we're not replacing existing event sources or sources of asynchrony. Instead, we can build bridges and expose those as observable sequences. Building this particular bridge is incredibly straightforward, too.

Cheers,
-Bart

PS: In a former life, I was a developer on WPF, so yes, I'm very well-aware of what that particular platform got too .

posted by bdesmet

Funniest quote of the talk: "Nobody thinks of a mouse as a database. They look at you and they lock you up somewhere."

posted by exoteric

Hope this helps,
-Bart

posted by bdesmet

Since async/await is in ctp, I am using a combination Task.FromAsync() and Unwrap() to handle composition of async operations. Now, Rx looks to me like good tool for observing a "stream of Tasks".

Could you elaborate if and how Rx and Task<T> fit together, especially with the Async Ctp? On the first look, there seem to be similarities between the two.

posted by mdk

First of all, from an interface point of view, IObservable<T> and Task<T> share the same mode of data acquisition, with data being pushed at you through a continuation (cf. IObserver<T> and the Task<T> ContinueWith method). One difference lies in the arity of the data. While IObservable<T> can describe the acquisition of multiple values of type T (cf. OnNext), a Task<T> can only signal a single value. So, IObservable<T> is more general than Task<T> from a one-versus-many data-centric point of view. In other words, IObservable<T> is great to describe push-based streams of data (such as for event processing) while Task<T> covers the single-valued case. No surprise we have conversions from Task<T> into IObservable<T> in the Rx libraries. You could do the other way around as well, for example collecting an IObservable<T>'s data into an IList<T> which is wrapped in a Task<T>. Here you're loosing the timing information of inidividually acquired values though (read on).

Now on to the Async CTP. What the new async features in C# and VB are all about is sequential composition for asynchronous programming. It's all about writing code that runs in response to an asynchronous task's (task used in the broadest sense here, not just Task<T>) sequentially with respect to the code that triggered the operation. In reality, the compiler turns the sequential-looking code into a continuation on the asynchronous task:

var res = await op();
Console.WriteLine(res);

This really turns into something along the following lines (in reality much more complex using a state machine much alike iterators, and with a check for BeginAwait's Boolean return value):

var aw = op().GetAwaiter();
aw.BeginAwait(() => {
    var res = aw.EndWait();
    Console.WriteLine(res);
});

The implementation of GetAwaiter depends on the return type of the "op" call above. In case it's a Task<T>, the awaiter represents an entry-point to establish a ContinueWith operation passed to the BeginAwait method. However, the compiler is by no means tied to any particular implementation of the "await pattern" and will choose whatever is available through regular method resolution (instance methods first, then extension methods, all regular rules apply). In particular, the Rx library implements the await pattern for IObservable<T>:

var res = await Observable.Range(0, 10);
Console.WriteLine(string.Join(", ", res));

To conclude, let's give an other observation (pun intended) here. Rx and async/await are totally complementary. I think we all agree that both technologies deal with asynchronous programming. One difference is in the arity of data, another is in the way you perform composition. We've seen exactly this coexistence situation for synchronous programming as well. Here are the two language features I'm talking about:

• ; - No, not a typo: semi-colon. Semi-colon is the way to sequence synchronous code operations in imperative style languages like C#. It's also your way to flow data out of an operation, into a variable and propagate it to the next operation.
• Query expressions, aka LINQ - This allows for composition over sequences of data by chaining (sequencing) together query operators through a fluent method invocation pattern. This is not your typically control flow, but totally complementary to the above.

Today we're seeing this repeated for asynchronous programming. For the first bullet point, we now have the await keyword, which allows code-centric sequencing of asynchronous operators. For the second bullet point, LINQ can be used to operate on sequences of data (using a pipelining mechanism for sequencing) such as IObservable<T> collections (or IAsyncEnumerable<T>, search C9 for more information on that one's role). Both can nicely coexist.

Hope this helps!

posted by bdesmet

Glad to see they are complementary, considering the past ways for async operations I was kind of worried.

I wouldn't have seen ; : linq = Task : Rx if it poked me in the eye - but it makes perfectly sense!

Thanks again!

posted by mdk

posted by Thorium

• I can't really debug Unit tests when using Silverlight Reactive Extensions (Silverlight Rx library with .NET core test cases).
• One case when calling .Subscribe() I get an exception before onNext evaluation: "Collection was modified; enumeration operation may not execute." But I don't know which collection! How can this be possible, I thought that Observables are like "history of events", and you can't modify history... Because this is before the first onNext, I don't find a way to debug.

And questions:

• Ain't there pdb-files to debug the Rx core...?
• Should I dispose manually? When?
• How will Rx work with Silverlight two-way data binding?

posted by Thorium

posted by bdesmet

posted by grogru

posted by GreenRoomTech

posted by priyamjm