You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the code from the fatfs example could be moved to the crate and adapted to expose functions more like those in std::fs.
For example, the code in mkdir could become something like std::fs::create_dir<P: AsRef<Path>>(path: P) -> Result<()>. We might be able to provide a new platform-specific implementation of DirBuilder, or at least model the implementation on that.
We could also implement create_dir_all and parts of the API that make sense rather than having consumers reimplement the same thing themselves.
The text was updated successfully, but these errors were encountered:
What do you think of an API strategy like the log crate? I.e. the icfs crate keeping a global trait object, along with a set_system(sys: impl FileSystem) that sets the global.
Then all std::fs-like functions can be exposed on icfs and implemented once for all filesystem implementations.
The con is potential tiny overhead of dynamic dispatch on trait object, and also overhead of taking locks on a RwLock or whatever.
Some of the code from the
fatfs
example could be moved to the crate and adapted to expose functions more like those instd::fs
.For example, the code in
mkdir
could become something likestd::fs::create_dir<P: AsRef<Path>>(path: P) -> Result<()>
. We might be able to provide a new platform-specific implementation ofDirBuilder
, or at least model the implementation on that.We could also implement
create_dir_all
and parts of the API that make sense rather than having consumers reimplement the same thing themselves.The text was updated successfully, but these errors were encountered: