Should the CancellationToken be a seperate parameter or should be a property on the FetchInfo #2548
Closed
inforithmics
started this conversation in
Development
Replies: 1 comment
-
RefreshData is something the users calls so I don't think they should be bothered with a CancellationToken. But I don't think FetchInfo should have one either. Rather I was thinking this should be encapsulated by the MapControl or Map. Let's discuss this further in the issue. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In this Pullrequest #2541 I add the CancellationToken to certain operations that run async Code to abort them.
There are now 2 possibilities to add this to the
Pro: No interface change
Contra: less visible that this method supports a CancellationToken.
Pro: immediately visible that it supports CancellationToken
Contra: Interface is changed so implementators need to change it.
Currently I have implemented option 1: Because it breaks less Code. I only wanted to ask what's the general opinion about this. I don't have a strong opinion about it. In the dotnet framework option 2 is taken, and the compiler can issue warnings when a cancellationtoken is not given to called methods.
Beta Was this translation helpful? Give feedback.
All reactions