I like Caliburn a lot and therefore I try to explain how it works to other developers. The hardest part to explain is often the coroutines.

I find that sometimes the naming of IResult is a pedagogical problem. I often find myself telling other developers to think about IResult as IAsyncTask or IAsyncCommand instead. "When you have IEnumerable<IResult> and are yield returning you are actually returning async tasks that gets executed while your calling code waits."

I would personally find it easier to understand if the names were something like IAsyncTask and IEnumerable<IAsyncTask>.

I also see a lot of misunderstanding about Coroutine.Execute(). It seems like many developers think this is a shortcut to synchronous execution of an IEnumerable<IResult> (ie. they think it will return once all IResults have executed in full). Here I think the name Coroutine.BeginExecute() would be more pedagogical. This would be the same convention as in many of the the .NET frameworks async calls.

Please don't take my comments as critisim. I'm not saying that the naming is wrong, because as usual there is no wrong or right names. I just wanted to share my personal oppionions and experiences in trying to explain coroutines to other developers. Perhaps others have different experiences and want to share some tips how to explain this stuff?

Also I want to ask if there is some logical reasoning behind the name IResult that I can use when explaining coroutines to developers?

That's good feedback and I agree with you. The name IResult was inspired by MVC framework's actions. It existed before I had IEnumerable<IResult> and before IResult had a Completed event. At that time it was used primarily for advanced view manipulation scenarios rather than co-routines. As I began working with it more and more I realized I could add the Completed event, and that helped in certain async scenarios. Then I eventually realized I could create a special enumerator for IEnumerable<IResult> and the coroutine implementation was born. While the implementation and usage evolved, the naming remained the same. Unfortunately, it's probably too late to change the name for this version. I am already mentally planning the next version of Caliburn.Micro which will support C#5. In that case IResult will be replaced with Task and probably some additional stuff to propagate the execution context. So, we'll eventually get this problem solved the right way.

Regarding Coroutine.BeginExecute. That is a good recommendation and one I am willing to break users on  ;) I'll make that name change. I've seen a number of people getting confused by this too.

Interesting background info, thanks :-). I think the evolution into coroutines is great, it simplfies async programming a lot.

At one point I was considering making an extra interface that would inherit IResult, eg. "public interface IAsyncTask : IResult"  to have the possibility use IEnumerable<IAsyncTask>. But I don't know if this will work seamlessly with Calibrun, eg. will conventional binding find IEnumerable<Something_that_inherits_IResult>? If this was possible we could have compability with old code but also have the possibility to use a new name. Perhaps the opposite would be easier... if there was IAsyncTask in Caliburn and IResult inherited it....

Anyway if you are thinking of a new name for IResult in future what would it be? If I try to make my own inherited interface I would of course like it to use the same name as in future Caliburn versions :-).

In a future version, I'm not sure if it will even need to exist yet. I have to do some serious experimentation with the C#5 async CTP.

Wow, the Task Parallel Library looks cool. I did not realize it is a part of .Net 4. Is there a reason you did not make use of it in Caliburn.Micro, since it is built on .Net 4? Was it just easiest to port the existing IResult system?

Yeah. Mostly backwards compat...and I'm not sure it is available in WP7.

You might find this interesting. I asked the following question to Jeffrey Richter, concerning his AsyncEnumerator (his version of a iterator based Coroutine):

My Question:

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.