Closed d2dyno1 closed 8 months ago
We can for sure create extension methods for OpenReadAsync
and OpenWriteAsync
/OpenReadWriteAsync
.
As for removing the default value here, after thumbing through the official dotnet APIs (e.g. FileStream
, File.Open
, etc), I'm inclined to agree. Conceptually, just opening a stream to a resource implies nothing about the read/write preferences for that resource, so a default value shouldn't be used here.
This will be a very broad-impact breaking change and will affect both implementors and consumers everywhere IFile
is used.
We should have more discussion on this before committing to a timeline for this change, I'd like to hear from others. Update: We'll make this part of the next breaking batch.
The problem
The current
IFile
interface contains a functionOpenStreamAsync()
which opens the file in read-only mode.This might cause erroneous behavior when trying to open a file in a read-write mode without an indication of it.
The solution
Remove the default flag for the
accessMode
parameter:and let the user create additional extension methods (
OpenReadAsync()
,OpenWriteAsync()
) for opening the file at their own discretion.