Open RAAvenger opened 1 year ago
Tagging subscribers to this area: @dotnet/area-system-threading-tasks See info in area-owners.md if you want to be subscribed.
Author: | RAAvenger |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `area-System.Threading.Tasks` |
Milestone: | - |
Just adding methods to an interface is a massive breaking change, so it's not going to happen.
Adding them as default interface methods is much less of a breaking change, but then the question becomes what the default implementation should be and I'm not sure there is a good answer to that.
Can't you mock DbDataReader
for your tests instead?
thanks for your suggestion. using DbDataReader
will resolve my issue.
A non-breaking option that comes to mind is to define a new Interface (e.g. IAsyncDataReader
) for all those async method overloads of DbDataReader
class and let DbDataReader
implement the aforementioned interface alongside the existing IDataReader
Background and motivation
I'm writing a code that exposes an NpgsqlDataReader. I would like to use async methods of DataReader and also be able to test my code by mocking DataReader, so i prefer to expose an IDataReader that can be mocked but if i do this i can't use async methods. Of course there is workaround like writing wrapper and ... but it would be great if the interface contains async methods.
API Proposal
API Usage
Alternative Designs
No response
Risks
No response