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
FilePath is good, but we sometimes need to process POSIX paths or Windows paths specifically, regardless of the current platform. eg. when we create our own file system, we may want it to stick to POSIX paths for various reasons: cross-platform consistency, simplicity, tool compatibility, etc.
The biggest problem appears to be, FilePath is implemented as a whole and the Windows and POSIX parts of implementation are highly coupled. Here is the ideal layout:
/// Unify `FilePath` APIspublicprotocol FilePathProtocol {…}/// Default implementationextensionFilePathProtocol{ … }/// POSIX path structpublicstructPOSIXPath:FilePathProtocol{ … }/// Windows path structpublicstructWindowsPath:FilePathProtocol{ … }/// The current `FilePath`#if os(Windows)publictypealiasFilePath=WindowsPath#elsepublictypealiasFilePath=POSIXPath#endif
However, these two new types do need to rely on the same set of Root and Component, then we may also need:
This is a generally high-level layout that can be used beyond simple system programming. eg, [email protected]:/bin/sh can be parsed into root [email protected]:/ and components ["bin", "sh"] (and the latter may reuse POSIXPath.Component). This model is also applicable to OSS, where Root is defined as storage buckets.
It's a nice idea. I think it's valuable to have all implementations available on all platforms.
I'm not so sure about adding a protocol hierarchy to abstract the different concrete FilePaths, though. Basically everything will want to use the system's native path type.
FilePath
is good, but we sometimes need to process POSIX paths or Windows paths specifically, regardless of the current platform. eg. when we create our own file system, we may want it to stick to POSIX paths for various reasons: cross-platform consistency, simplicity, tool compatibility, etc.The biggest problem appears to be,
FilePath
is implemented as a whole and the Windows and POSIX parts of implementation are highly coupled. Here is the ideal layout:However, these two new types do need to rely on the same set of
Root
andComponent
, then we may also need:I’d like to collect some feedback for this change & ideas on how to implement this in the correct way.
The text was updated successfully, but these errors were encountered: