Introducing FoundationLite framework as a portable subset of Foundation

No disagreements that FileManager is a beast that does a lot (more than I even understand), but I do think it should be replaced :grimacing:. Even your updated version doesn't feel very swifty to me. It lacks a lot of the strongly typed features that so much of the language has in other areas.

Paths shouldn't just be generic strings/urls (I'm ok with the underlying storage being a string/url). There should be separate types for the various path types (ie: DirectoryPath, FilePath, etc) because each path type has different sets of functionality. Rather than interacting with paths via FileManager, I'd prefer to be able to do everything on a Path directly. For example, you shouldn't be able to incidentally try getting the subpaths of a FilePath, this is something that should be limited to DirectoryPaths.

Converting your example to what my ideal Swift Path library would be:

let supportDir = DirectoryPath.applicationSupportDirectory(inDomain: .user, options: .createIfNeeded)
let newFile: FilePath = supportDir + "file.extension"
if !newFile.exists {
    let resource: FilePath = Bundle.main.file(forResource: "file.extension")
    try resource.copy(to: newFile)
}
doStuff(path: newFile)

Of course, I'm not very familiar with Bundle nor do I have any idea what the FileManager domains stuff is.

2 Likes

As a server-side developer, I don't actually know what "application support directories" and "bundles" are, so I suspect these are not strictly portable concepts. :) As such, they could be maybe part of a library separate from one that does just basic file I/O.

1 Like

Open question: is it a good idea to let paths access the file system? There is a global state there.

The current API, where all accesses to the file system are done via a FileManager instance, avoids this problem. You can write tests against a virtual file system, for example.

I was thinking the same thing. Much of FileManager is Apple/iOS specific and would probably not be necessary for a potential stdlib Path library. The Apple/iOS specific stuff could be kept in Foundation and just extend the stdlib Path types with support for Bundles and whatever else is needed.

No, that would only lead to apple api being a special case and not the norm. Why should I as a mac coder support such a development? For what gain? That Linux guys are happy?

Looking around at some of the Swift Path libraries out there, they're almost all just wrappers around FileManager, but they seem to only really focus on giving more swifty access to the local file system. (Some do allow you to overwrite the FileManager used though)

You do bring up a good point. There probably should be functionality for testing against virtual file systems.

Perhaps by overwriting the root directory with a virtual one:

Path.root = DirectoryPath("/").virtual

Swift is supposed to be a general purpose programming language. You may disagree with that, and maybe this is more an aspiration than current reality, but that's what I understand it to be. As such, yes, Apple would be a "special case" and not the norm—just as any other platform. I don't see why this should be a bad thing, nobody is saying there shouldn't be good, useful libraries for working on Apple platforms, just that there should be a separation of concerns so the non-platform-specific stuff is reusable. ¯_(ツ)_/¯

5 Likes

We have virtual filesystem and path APIs in SwiftPM. They've proven to be really nice and lets us run unit tests at the speed of light!

https://github.com/apple/swift-package-manager/blob/master/Sources/Basic/FileSystem.swift#L502
https://github.com/apple/swift-package-manager/blob/master/Sources/Basic/Path.swift

5 Likes

Because cross platform solutions EVERY single time lead to the same posix crap. And any system with better features has to live with that insane and broken api 8( I'm fed up with any languages io libraries only working ok on posix.

You do realize that Apple platforms are mostly POSIX compatible?

The point of a Swift Path library would be to use the POSIX APIs (on Apple and Linux platforms) to give a clean, consistent interface with file system I/O. Windows and other platforms would interact using whatever their platforms I/O APIs are.

You may hate the POSIX APIs, but they make it a lot easier to write cross-system compatible libraries. By writing wrappers around POSIX APIs, you automatically support both Linux and mostly Apple (only minor changes required for full macOS support). This would be much better than forcing Linux, Windows, etc to use hacks in order to work with the current Apple-only Foundation APIs in a general purpose programming language.

2 Likes

I'm not going to further interject on the topics at hand here, but I would like to request that people be a bit more mindful of each other while debating, given that the discussion has certainly veered far from its starting point.

9 Likes

No the posix api in macOS are as useless as they are elsewhere. They have to die and die fast, why are people glamoring this broken stuff?

Have you ever used macOS for coding that you see that old crap as sensible common ground? I do not. Apple coders always have to suck up the posix api every language throws at them, not it's time for you to be in the same boot and be on the a little worse side.

I'm saddened that you feel this way. My intent is not to "overtake an Apple-based project", but to help enhance it. This project may have begun at Apple, but it is meant to be used outside of Apple. My intention is simply to improve cross-platform support since even the Apple core team has said that cross-platform support is a goal of the Swift language. This is simply not possible if the language continues using Apple-specific code for large swaths of the codebase.

4 Likes

Jan, please keep a professional tone here. Everyone has different goals, different visions for what they want Swift to be, and different ideas on how to get there, but we all want to make things better. You've made your perspectives clear.

7 Likes

You seem to have an irrational hatred of Linux. You're free to like and prefer whichever platform you prefer (I'm sure everyone has their opinions there), but I'd like to remind you of what a success story Linux is: It runs basically everywhere, from tiny embedded devices to servers, from consumer applications to the Large Hadron Collider. That's not something you can say about either Windows or Mac, whatever their merits. That has a lot to do with the effort to keep things platform-independent and having a simple model to think about the OS (like: everything is a file, small single-purpose tools, etc.).

That's a big reason for wanting Swift to succeed not only on Apple, I'd say.

Why should I as a linux coder support iOS-centric development? For what gain? That the apple guys are happy?

see where i’m going with this?

2 Likes

This comment captures my sentiments as well. Discussions on the forums can serve as a rock tumbler for ideas, but discussions need to remain civil and follow the Code of Conduct from the project.

Moderators will delete posts violating the code of conduct (as I just did for one post on this thread).

5 Likes

I would prefer enhancing the current FileManger API instead of trying to create a new hyper-typed approach in a library like Foundation that should remain very general purpose. IMHO this type of more opinionated and custom API would be better left in external packages (like PathKit).

FileManager is a really powerful API and with some changes and additions it could become a lot more Swifty. Using URLs instead of String is a good example.

(As a side-note, I completely agree with @jrose. Good and clear debate requires civil behavior.)

3 Likes

There is an open pull request by @millenomi to add support for it on Linux :slight_smile:

2 Likes

That’s the kind of thing I mean when I say I wish the Foundation APIs were more swifty and “hackable”. Lots of higher-level code wont really care about where files are stored, i.e. whether or not they are literally written to persistent storage on the local machine somewhere. It would be cool to be able to plug a web service/SFTP connection/SQLite database in to those components.

Another example is the use of enumeration blocks (e.g. in Calendar). They often include inout Bool parameters to stop iteration. I think those kinds of things are better expressed as Iterators, which would allow you to wrap them as Sequences , use them in for loops, “map” their values, etc.

But I think those kinds of changes are better discussed in another topic. It doesn’t have much to do with modularising Foundation, IMO.

1 Like