Closed swankjesse closed 3 years ago
To your point, this is really handy for tests, and I can see some of those operations being generally useful.
I'm becoming more hesitant on this. Normally I think we try to cover about 90% of use cases in our API design but I'm worried here we're going to far undershoot that number by being biased towards our current usage. And since Okio isn't a library that we really want to do a v2 or v3 on in any such frequency perhaps this would warrant itself as a standalone library that we can take through 0.x cycles? If you give me an hour I bet I can amass use-cases from all our libraries (public and internal) that would require a significant expansion of this API to support.
On Sat, Jan 21, 2017 at 8:38 AM Dave Roberge notifications@github.com wrote:
To your point, this is really handy for tests, and I can see some of those operations being generally useful.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/square/okio/issues/282#issuecomment-274262302, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEc9wD_7yYb4bkAWZnyIV6JJeQINfks5rUgpogaJpZM4Lpx4Q .
Duplicate of this: https://github.com/square/okio/issues/797
Should we get an interface like this? https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/internal/io/FileSystem.java
It makes tests run fast (no actual I/O) and it makes testing easier. The
java.nio
alternative is complex and awkward.