Monday, April 12, 2010 1:54 PM
event system is reactive, you are reactive to an event
reactive extensions is also reactive
it is somehow blurry to me,
i imagine it this way,
we use event system when u are handle hand gun ( a bullet == single event fired)
we use reactive extensions when u are handle machine gun (lot of machine gun bullet == collection of event stream)
is this correct ?
any other thing which i should know about possibility of reactive extensions ?
My Brain Speak
- Changed Type head.in.the.boxOwner Tuesday, April 13, 2010 7:57 AM
Monday, April 12, 2010 2:25 PM
Your conceptual model is inaccurate. An event can be raised multiple times, just like an observable may produce multiple values.
The choice, IMO, is entirely based on usage requirements.
Use events when:
- You are implementing an event member defined by an interface or an abstract base class.
- You are creating an ASP.NET control and want to enable declarative event registrations.
- You are creating a UI control and want to interoperate with the Visual Studio UI designer and Properties window. (WinForms, WPF, Silverlight, etc.)
- You are creating a component and your application uses the PropertyGrid control to host an instance of your component, and you would like to have events shown on an Events tab.
- You are using reflection to quickly discover the event members on a type at runtime. (You could do this with IObservable properties as well, but arguably it's much easier using events since they are first-class as far as reflection is concerned; furthermore, it may not be your code doing the reflection - see #3 and #4 above.)
- The semantics of your event has no compositional value (although I'm not sure if that's something we can really know for sure when designing a type.)
- You need to interoperate with legacy .NET 2.0 code that doesn't support IObservable.
I'd use IObservable in all other scenarios.
Monday, April 12, 2010 2:45 PMHi Andrew, if .NET was rebuilt, they'd probably replace the event model entirely with IObservable (or reimplement it based on IO). IO allows you to implement events, but also do a lot more. Any computation and control flow can be modeled by IO, actually. IO is a push based collection so, like IEnumerable/IEnumerator (a pull based collection) is used to implement things like foreach, IObservable/IObserver can be used to implement various things, including, but not limited to events. Hope that helps.
Monday, April 12, 2010 4:43 PM
Maybe u can describe it what u mean with others scenario ?
Also, is it possible on Rx, that we know how many items on collection which to be handled,
say, i'm only handle 5 items of a collection each its retrieved ?
i do realize that make it 5 times do the blocking however, but maybe on some case we need it ?
I watch Rx video by Erik, so far i'm only know when using it during event, async event
its looks like i can throw away my backgroundWorker and timer
what do u mean by that various thing ?
My Brain Speak
Tuesday, April 13, 2010 7:36 AMOwner
Not sure that I understand your gun analogy.
One way to view Rx is simply as "first class events" (which is exactly what F# does), and as the event-based async pattern (http://msdn.microsoft.com/en-us/library/wewwczdw.aspx) shows, events can fire zero, one, n, or an infinite number of times. Just like enumerable sequences, which can be of any length.
Another way to view Rx is as a compositional way to realize the Subject/Observer design pattern in particular such that it supports the LINQ standard query operators.
That said, the best way to learn Rx is to actually write some code. Take some event-based code you have written before and try to refactor it to leverage Rx.
Hope this helps
Tuesday, April 13, 2010 7:54 AMOwner
Sounds like maybe you'd want to use the various Buffer operators, that chop observable streams into chunks. Or if you want to only react to a prefix of the stream you may use Take.
Note that Rx is not meant to replace any existing concepts. Its purpose is to provide a high-level mechanism to compose standard asynchronous and event-based computations such as BeginXXX/EndXXx pairs, Task<T>, events, .... Just like IEnumerable is not replacing the various concrete collection types such as List<T>, T, ... but is a common interface that allows you to glue together different kinds of collections in a uniform and high-level fashion.
We do not believe in "10x better" but instead we follow the Change Function and focus on targeting real problems with zero pain of adoption, which means that we strive to leverage all your knowledge and investments in existing technologies in order to make programming the Cloud simpler.
Tuesday, April 13, 2010 1:41 PM
> Maybe u can describe it what u mean with others scenario ?
Any time you create an event that doesn't fall into one of the aforementioned categories, consider using IObservable instead. Most of the time you'll find that IObservable is better.
Tuesday, April 13, 2010 3:08 PMHi,
yes will do coding, will get visual studio express 2010 today, as tomorrow have silverlight 4, will start coding
one bullet = 1 event fire = handgun
n bullet = n event fire = machine gun
sorry for such strange analogy, too much playing modern warefare
ok i can conclude it like this,
at this moment, use Rx for event stuff first, until i get aha !, maybe can implement it on something else
Thank you for the help and support