Add extensions to improve out-of-box experiences about okio HOT 4 CLOSED

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.

from okio.

The ones for file system (they're all for file system)

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.

from okio.

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.

from okio.

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.

from okio.