-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Make AsyncTaskCodeActivity derive from AsyncCodeActivity instead of TaskCodeActivity<object> #186
Comments
I'm also a bit confused on why there is an |
Hi all, perhaps I can provide a bit of history here. I'm the author of the
My original proposal had both the generic and non-generic AsyncTaskCodeActivities implementing their respective AsyncCodeActivity and translating the old asynchronous methods into TPL-style. @lbargaoanu had proposed that, in order to help facilitate code deduplication, the If this TaskCodeActivity base class is causing issues for consumers, I'm perfectly fine deleting it. This should in theory be a non-breaking change since the AsyncCodeActivity type is an internal implementation, but we will need to be careful to ensure the transition does not affect public-facing code adversely. |
The
AsyncTaskCodeActivity
should not have aResult
property. This causes problems in some scenarios with reflection and validation.There are two ways to solve thje problem:
Create a
TaskCodeActivity
as a companion forTaskCodeActivity`1
or let theAsyncTaskCodeActivity
derive directly fromAsyncCodeActivity
.Here's an example implementation, which uses
AsyncCodeActivity
directly, as theTaskCodeActivity`1
implementation looks unnecessary even though there is a little bit of code duplication:The text was updated successfully, but these errors were encountered: