-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add extensions to improve out-of-box experiences #1458
Comments
These fundamentally undermine a principle of the design which is that code is agnostic to the actual FileSystem with which it's interacting. More concretely, using these extensions (in a library, say) breaks my ability to use the contents of a zip without extracting. Or files in an Android app's asset directory. Or files that live on a remote machine like AWS S3 bucket. With Kotlin's upcoming context parameter language feature, it's possible that the FileSystem context could become implicitly propagated rather than implicitly. Until then, accepting a FileSystem anywhere you accept a Path is the correct design pattern. |
You can use extensions like these in your project so long as you're not a library. If you're a library, and you accept a Path from a user, you really must also accept a FileSystem or you break a bunch of use cases. If you are in an application that only uses the system FileSystem then these are relatively safe. |
Yes, that's why I call it "out-of-box experiences." Because I only want to call the system FileSystem, it would be best if Okio could provide some extensions for JVM (including Android) and native platforms. What I am asking is, indeed, for the upper layer. We can achieve this by placing it in different source sets, instead let users write again and again. |
I think we're stuck waiting for context parameters where we don't need to choose between convenient-but-inflexible and verbose-but-flexible. We explicitly do not want to make it easier to implicitly introduce a static dependency on the system file system that makes code harder to test and less flexible in the library case. |
Hi, I am just wondering if we could add something like the below to improve out-of-box experiences.
For example (incomplete)
The text was updated successfully, but these errors were encountered: