Skip to content
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.

Sign up for GitHub

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

Jump to bottom

API Request: Splitting POSIXPath and WindowsPath out of FilePath #67

Open
stevapple opened this issue Nov 4, 2021 · 2 comments
Open

API Request: Splitting POSIXPath and WindowsPath out of FilePath #67

stevapple opened this issue Nov 4, 2021 · 2 comments

Comments

@stevapple
Copy link
Contributor

stevapple commented Nov 4, 2021 •
edited
Loading

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` APIs
public protocol FilePathProtocol { … }

/// Default implementation
extension FilePathProtocol { … }

/// POSIX path struct
public struct POSIXPath: FilePathProtocol { … }

/// Windows path struct
public struct WindowsPath: FilePathProtocol { … }

/// The current `FilePath`
#if os(Windows)
public typealias FilePath = WindowsPath
#else
public typealias FilePath = POSIXPath
#endif

However, these two new types do need to rely on the same set of Root and Component, then we may also need:

public protocol FilePathRootProtocol { … }
public extension FilePathRootProtocol { … }
public extension POSIXPath {
    public struct Root: FilePathRootProtocol { … }
}
public extension WindowsPath {
    public struct Root: FilePathRootProtocol { … }
}

public protocol FilePathComponentProtocol { … }
public extension FilePathComponentProtocol { … }
public extension POSIXPath {
    public struct Component: FilePathComponentProtocol { … }
}
public extension WindowsPath {
    public struct Component: FilePathComponentProtocol { … }
}

public protocol FilePathProtocol {
    associatedtype Root: FilePathRootProtocol
    associatedtype Component: FilePathComponentProtocol
}

I’d like to collect some feedback for this change & ideas on how to implement this in the correct way.
@stevapple
Copy link
Contributor Author

stevapple commented Nov 4, 2021 •
edited
Loading

This is a generally high-level layout that can be used beyond simple system programming. eg, user@example.com:/bin/sh can be parsed into root user@example.com:/ 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.

@karwa
Copy link

karwa commented Nov 4, 2021

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.

@stevapple stevapple mentioned this issue Dec 6, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@karwa @stevapple