Jan 29, 2011 at 6:17 AM
Edited Jan 29, 2011 at 6:17 AM
You might find this interesting. I asked the following question to Jeffrey Richter, concerning his AsyncEnumerator (his version of a iterator based Coroutine):
Now that the Async CTP has been announced and described do you see it as complimenting, replacing or just as an alternative to AsyncEnumerator? Will the CTP affect the future of AsyncEnumator?
I has very heavily involved with the creation of the new Async features that Microsoft has added to the next version of C#/VB.
We had monthly meetings that lasted well over a year and the survey that I asked members of this group to take several months ago directly affected the final implementation.
In essence, the new async feature in the language is just like the C# iterator feature except that the await keyword is used in place of ‘yield return’. The new keyword feels
more natural and it can be used in an expression context as opposed to a statement content which simplifies your code allowing it to be more composable. Also, async methods can invoke other async methods which is a huge improvement over what iterators allowed
you to do. This allows you to have async subroutines which you can call from other async (or non-async) methods which also allows for composition. My AsyncEnumerator also supports this but it is much more clumsy to do.
The new async feature centers on Task which offers three big benefits. First, it is just easier than using Begin/End/IAsyncResult. Second, if unifies performing compute-bound and I/O-bound
operations around a single construct. Three, it integrates the SynchronizationContext into it which is another big improvement over Begin/End. All of this yields a lower concept count for programmers and things work more naturally. Also, I don’t know
if MS will officially obsolete or deprecate the event-based APM (like BackgroundWork and WebClient classes) but they definitely should discourage people from using classes that follow the event-based pattern. This pattern has always had many problems with
it and I feel strongly that it should have never been produced in the first place. The new async stuff is much better than what the event-based pattern has to offer.
As for AsyncEnumerator:
I love the new async .NET stuff and it was definitely the right thing for the team to do. Remember that it is in its infancy right now and that the team will add better debugging and other
features as time goes on. My AsyncEnumerator will continue to be available for those that need .NET 2.0 or later support and I will keep it working with new versions of C#/.NET so that people are not forced to port their code over to the new model. I may try
to enhance the new async model with better debugging features and other things that AE currently offers which the new model does not offer today. I feel that I have been very responsive to AsyncEnumerator users and I intend to continue to do that. I can certainly
be more responsive than Microsoft can and can deliver features or bug fixes more quickly,
Personally, I am very proud that my AsyncEnumerator and its success played such a huge part in the industry and that I was able to assist Microsoft in producing the new async features. My
goal has always been to try to make it easy for others to build scalable and responsive applications and components and I feel that I am playing a big part in this which is very rewarding.