Support Task<T> In ProxyGenerator

[VaughnVernon]

For anyone with a spare hour or so, this is a pretty simple contribution.

Support Task<T> as a valid type in the ProxyGenerator. Inside the ProxyGenerator you will see the current Completes<T> support, and this type can be added along side it pretty easily.

NOTE: Task<T> will not be used for vlingo-net-platform internals or public APIs. We will continue to use Completes<T> for core vlingo-net-platform protocols. Consumers will for sure want to use Task<T> as a return type in their protocols. We will provide sufficient warnings in the docs regarding the use of Task<T>, but some will think it's a great idea and insist on its support.

[tjaskula]

@VaughnVernon I have looked in more details into the current implementation and it seems it's not so easy as described.

• ICompletes is supported in the IMailbox signature of void Send<T>(Actor actor, Action<T> consumer, ICompletes completes, string representation); where Task<T> isn't.
• ICompletes is supported in LocalMessage constructor.

So we cannot just return a new Task<T> out of nothing because it would not make any sense. The best solution would be able of converting ICompletes to the Task<T> but that would mean making async-awaitable ICompletes first.

[VaughnVernon]

@tjaskula I agree that we need to convert between Task<T> and ICompletes<T>. However, for IMailbox and Send<T> it might be best to create a Returns wrapper that can hold either type, enabling actors to use either. I think that diverging from Java in this one case is worth it. WDYT?

Actually we will end up doing the same in Java to support CompletableFuture and a few others.

[tjaskula]

@VaughnVernon Actually you mean that Send should be returning a wrapper Returns instead of void right ? But we still have to handle Task inside the mailbox implementation that can be handed to the client (either wrapped in Returns or not).

[VaughnVernon]

@tjaskula Nope. I mean that the Send method signature will change:

void Send<T>(Actor actor, Action<T> consumer, Returns returns, string representation);

In the Blah__Proxy you will create a Returns from the type of return value, ICompletes<T> or Task<T>, both supported by Returns. Then the Proxy will return either the ICompletes<T> or Task<T> that was created in the proxy invocation. Or you can do this:

void Send<T,R>(Actor actor, Action<T> consumer, R returns, string representation);

And make the send adapt. I think I like the first better because then you don't need to create an IReturns and then a ReturnsCompletes and ReturnsTask. But let me know what you prefer and we will do the same in Java.

[VaughnVernon]

@tjaskula Actually probably the second approach is better because less memory for two return types, and if we support other return types in the future then we can just add a new implementation class. So let's do the second option.

[VaughnVernon]

@tjaskula Sorry, just a stream of consciousness going here. I should have slowed down a bit 😃

void Send<T>(Actor actor, Action<T> consumer, IReturns returns, string representation);

With: ReturnsCompletes and ReturnsTask implementations.

[tjaskula]

@VaughnVernon Thanks for clarification. I'm not sure yet about the details of the implementation. I might as well try to make ICompletes task compatible if it's not to difficult. I have to try different ideas. I'll come back to this thread once I started experimenting.

[VaughnVernon]

@tjaskula I think this can be put onto a Projects card for actors and we can discuss later.

[tjaskula]

The proxy generation has to be improved in order to handle specific needs of async/await like for example

• mailbox suspension to avoid thread reentrancy into actors
• execution in specific to actor scheduling context.