Comments (5)
I also would like to add that kotlinx-io
's Path.toString()
may not necessarily be compatible to File
, for when the underlying object backing Path
would change (in the future). So having a dedicated Path.toFile()
conversion method would likely save us the pain of having to deal with any potential (future) incompatibilities.
from kotlinx-io.
I totally agree that these functions would be quite handy, and for now everything should work fine.
However, thinking of a direction we're going evolve fs-API, there might be some issues.
Currently, kx-io's Path
is always bound and interpreted as local file system's file path. Instead, a path should be bound to a FileSystem
instance (and yes, currently there's only one implementation), the same way java.nio does it (it's not a final decision, but we're gravitating towards it).
In that case kotlinx.io.files.Path
to java.io.File
conversion should work only if a Path
belongs to a local file system, in all other cases it should throw an exception.
For kotlinx.io.files.Path
to java.nio.file.Path
conversion we, potentially, can do better and try supporting it for other file system types (like, ZipFS). To make it work properly, a function responsible for conversion may need an instance of java.nio.file.FileSystem
a result Java path should belong to. Or maybe it doesn't need an fs instance, I need to check how and if it should work (just as a reference, java.nio.file.Path::toFile
fails for non-default filesystem).
from kotlinx-io.
Instead, a path should be bound to a
FileSystem
instance (and yes, currently there's only one implementation), the same way java.nio does it (it's not a final decision, but we're gravitating towards it).
Huge +1 to this design. Using Okio's FS APIs I sorely miss the NIO design.
from kotlinx-io.
Using Okio's FS APIs I sorely miss the NIO design.
Perhaps kx-io's Path
can be an interface, and then we could have a concrete implementation of it that wraps a File
.
Say for example, the concrete implementation is a class named FilePath
. Then with that, Path.toFile()
can be implemented as an extension function that simply casts Path
to FilePath
in order to take the wrapped File
. If the cast fails, then simply throw an exception.
Now, say Path
could return the FileSystem
it's associated with. When the cast to FilePath
fails, we could additionally check if the associated FileSystem
is the default or system one: if that additional check succeeds, then attempt to convert Path.toString()
to File
; throwing otherwise.
We could then mimic that design for other platforms, in case there's a much better platform-dependent object (similar to Java's File
) that Path
could wrap.
The downside to this is that, Path
is now dependent on the underlying FileSystem
that it's associated with: its string representation may now not be portable/convertible to other Path
objects if the associated FileSystem
is different. But I think that's actually a good thing.
Additionally, the default or system FileSystem
may interpret Path
differently depending on the platform and operating system – it's the "system" FileSystem
after all. But that too could actually be a good thing, as it avoids issues such as square/okio#1460 from Okio. An OS may even interpret null characters in a Path
as okay, yet some other OS may fail on such characters. Also, backslash (\
) characters should be valid in directory and file names on Unix, in case there exist a set of files that has a really exotic reason (perhaps a supernatural reason) for having backslash characters in filenames – see for example, “.NET 8 breaking change: Backslash mapping in Unix file paths - .NET | Microsoft Learn”
Suppose one wants a portable interpretation of Path
, where it's guaranteed that a slash (/
) is always interpreted as a file separator and all other characters are not (including backslash), then perhaps we could have a PortableFileSystem
that may wrap a FileSystem
object so that all Path
objects are interpreted as described, but may throw if a character isn't valid according to the wrapped FileSystem
object. That is, the only prominent difference between a PortableFileSystem(sfs: SystemFileSystem)
and SystemFileSystem
is that, PortableFileSystem
may throw, while treating all file separators as slash characters, as if it's some kind of view/filter over the wrapped SystemFileSystem
.
However, at this point, I'm getting off-topic, and I might even suggest a FileSystem.toPortable()
as a convenient extension function returning a PortableFileSystem
😉 – also, I believe implementing that PortableFileSystem
(perhaps accompanied by some PortablePath
) would be very complicated and tricky, at the same level of complexity rivaling Okio's platform-independent Path
objects. So maybe this last idea is not worth pursuing for now (at least).
from kotlinx-io.
P.S. That PortablePath
could even have "X:/"
, "x:/"
and "/"
interpreted as all valid prefixes denoting an absolute Path
. On Windows, the "/"
may be interpreted to have the same drive letter as some base Path
(which may default to the current working directory) that may have been passed to the PortableFileSystem
constructor. On Unix, paths starting with "X:/"
or "x:/"
may be interpreted as pointing to a nonexistent location (and thus may throw), or perhaps simply stripped away when finally converting PortablePath
to the wrapped FileSystem
's Path
object equivalent (the real equivalent of PortablePath
).
from kotlinx-io.
Related Issues (20)
- Consider moving core IO primitives to the standard library prior to their stabilization
- Investigate the potential mechanisms for project-wide opt-out from unsafe API HOT 6
- Improve SegmentPool test coverage
- Add support for writing other primitive arrays to Buffers HOT 2
- [help] How to read and write a file? HOT 4
- Add a way to check if Path points to a link HOT 2
- `readFromHead`/`writeToTail` should propagate the `Int` returned from the lambda HOT 2
- Lambda-accepting `UnsafeBufferOperations` need contracts for calls-in-place
- Rename `RealSource` and `RealSink` to `BufferedSource` and `BufferedSink` HOT 2
- Should `Source.buffer` be `@UnsafeIoApi` instead of `@InternalIoApi`? HOT 3
- Evaluate use of unsigned numbers for public API HOT 9
- Add support for atomic file creation
- Move smoke pre-release tests to kotlinx-io repo
- Provide Sink/Source implementations writing to stdout/reading from stdin HOT 11
- Use ByteArray.set<Type>At and get<Type>At to read/write from Segments on Native
- Tidy up samples to make them more kotlin-playground-friendly HOT 2
- FileSystem: missing a function to construct an absolute path from a relative one HOT 2
- FS: On Windows, use Win32 API accepting wide string to avoid issues with the file path encoding
- ByteString: provide ByteString-factory overload accepting unsigned bytes
- Temporary file creation support HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kotlinx-io.