Bart De Smet: Rx Update - .NET 4.5, Async, WinRT

Sign in to queue

Description

Bart De Smet has been very busy. As you can imagine, the latest release of Rx (v1.11011.11 (Experimental)) supports the latest (developer preview) .NET version, 4.5. In this release, Bart and company have forged a deeper synergy with the async/await Task-based asynchrony model (see Prefer Async Policy in the Release Notes for this release for more info and watch/listen to this conversation!). In addition, Rx can be used in "Windows 8" Metro style apps. Smiley

Rx v1.11011.11 (Experimental) features include:

Improved Exception Management

Prefer Async Policy

Interoperability with Task<T>

FromEventPattern Support for WinRT Events Various Changes to System.Reactive The New

System.Reactive.WindowsRuntime Assembly

This release of Rx includes support for WinRT interop and to build Metro style applications leveraging Rx for event processing

IAsyncInfo Conversions

Release Notes

Download

Embed

Download

Download this episode

The Discussion

  • User profile image
    Dylan Meeus

    Very nice!

  • User profile image
    felix9

    Still no native Rx ? Devil

  • User profile image
    tony

    Bart please start a blogging about rx with js...

    tia

  • User profile image
    Robert Baarda

    Where did you buy that shirt?

  • User profile image
    leidegre

    Charles, Rock NRoll is your thing, don't let anyone tell you otherwise!

    /Rock n' Roll!

    PS. listening to Bart is awesome!

  • User profile image
    Jeff

    This is awesome.

    I have a question, though: Since Task<T> is "the" abstraction for single-valued asynchrony, why not make IObservable's folding operators (Aggregate, First, Last, etc.) return a Task<T> instead of a single-valued IObservable<T>?

  • User profile image
    Maddus Mattus

    Because you want to continue using observables,..

    If it would return Task<T> you would be stuck.

  • User profile image
    felix9

    I think you should move those 'txt.Text = "<Stopped>"' statements out of the using block ...... no ?

    Update. oh, maybe even setting text.Text after Dispose() wont elimate the problem.

    I guess the scheduler or 'sync context' has a 'message queue' kinda thing, and if a 'txt.Text = Key' is already in the queue, unsubscribing or Dispose wont remove it from the queue, so it could be executed after <Stopped> and overwrite the txt.Text ? right ? Maybe the fact of you are subscribing to KeyDown events could help here since its in UI thread and message queue too, but what if you are observing something really 'async' ? Perplexed

  • User profile image
    ninjeff

    @Maddus Mattus: Did you watch the video? Bart talks about how IObservable<T> and Task<T> live nicely together in the new version of Rx.

  • User profile image
    Adam​Speight2008

    Could the capabilities of Project Roslyn, assist in "magic" strings problems on events, by provide compile-time checking? or would it require a change to the lexer / parser.

  • User profile image
    AceHack

    I like "Rock n Roll"  Keep saying it! Smiley

  • User profile image
    bdesmet

    @Jeff: While Task<T> would be a good fit for single-value asynchronous results coming out of the Rx APIs, there are a few things we don't want to get into.

    First of all, staying in IObservable<T> allows for further composition, which is very rich in the world of Rx. A typical example I always bring up is to apply the Timeout operator to the resulting sequence. With Task<T> you can do similar things using WhenAny or by using cancellation mechanisms, but it's less sexy.

    Secondly, by going to Task<T> there's an implicit change in scheduler affinity. Having the ability to control scheduling through the IScheduler abstraction and having a more free-threaded world is an advantage of Rx we don't want to loose due to implicit changes of primitives.

    Having said all of this, users can still go to a Task<T> object explicitly by using the ToTask operator. However, for the simple task (pun intended) of awaiting the result of such a single-valued observable sequence, support is right there in Rx to use "await" directly.

  • User profile image
    bdesmet

    @felix9: The test code you saw on the screen is not flawless indeed. In general, it's possible for the sequence to produce an OnNext message before the Dispose call to the subscription occurs. The fix is quite simple though: use the Finally operator in Rx to run code after the sequence completes or gets disposed.

  • User profile image
    bdesmet

    @AdamSpeight2008: Remains to be seen. Notice the trend of reducing magic strings in pretty much every recent release of the languages (e.g. LINQ instead of queries in strings, dynamic instead of invocation calls with member names in strings, call info attributes instead of hardcoding the current member's name, etc.).

    Personally, to reduce the event conversion friction I'd invest in a conversion of events to IObservable<T> like F# does, but at this point there are no such plans.

  • User profile image
    aL_

    cool stuff!

    i really wish anders will allow us to treat events like a normal multicast delegate properties, that way you could write extensions methods for things like rx on them Smiley

  • User profile image
    ligAZ

    Guys,

    Do you plan to release a version of Rx built against the Portable Library Tools?

  • User profile image
    exoteric

    Some clever work going on there. I really like the new WinRT event model and how it fits hand in glove with Rx. And of course the new exception handling enhancements to Rx looks really great. A lot of goodies in the box.

    Rock 'n Roll !

  • User profile image
    ninjeff

    @bdesmet: Thanks for the response, Bart.

    Seems like you had to pick between two slightly awkward choices: return a Task<T> and deal with the gaps and differences, or return an IObservable<T> that breaks the abstraction slightly.

    In a perfect world, I think Task<T> and IObservable<T> would have the exact same interfaces for the shared concepts that you mentioned. Given that they don't, though, the choice makes sense.

  • User profile image
    bdesmet

    @ligAZ: We're actively working with the PLIB folks on making Rx portable. The main thing required is to have IObservable available in all supported platforms. At this point, we can't commit to a time frame, but we're on it Smiley.

  • User profile image
    bdesmet

    @ninjeff: One thing that would help is to have Task implement IObservable. Given that any multi-value concept has the single-value case covered too, that'd be a good way to think about it. However, in the synchronous case, there's no such implicit conversion between a multi-value thing (e.g. an array) that happens to have a single value and its contents (an "unpack" operation). Rest assure we are (and will continue to be) thinking about co-evolution and co-existence...

  • User profile image
    Richard.Hein

    So this is what you couldn't talk about at Mix, isn't it Bart, otherwise you'd have been revealing WinRT.  Smiley  I was surprised to discover Wes has left the team.  He'll be missed. Sad  I wish him the best at his new venture.  I do wish you and Wes would blog again. 

    There must be something coming down the pipe related to Linq-to-Cloud, and NoSQL.  Can you tell us anything about that and how Rx relates?

     

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.