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
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
I'm not so sure about this. The specific abstractions will depend on your domain. You can't just dump random data that you would write into a text file into a relational database instead; nor can you just send it to any web service.
Plus, if you're working with web stuff, your API will probably need to be async, whereas the file APIs are synchronous (at least the ones I'm aware of).
In-memory file systems make a lot of sense, but beyond that I think you're better served defining your application-specific use case in, say, a protocol and then code different swappable implementations with whatever backends you might wish to support:
protocol ProfileStorage {
func write(key: String, value: String)
func read(key: String) -> String
}
1 Like
Mine was just a hand-wavey comment about how I like APIs to include substitution points ('hackability'). But okay...
"The filesystem" is already a well-defined abstraction by itself. You can have FAT, NTFS, HFS+, AppleFS disks on the same system, and almost no applications need to care about the differences between them. Similarly, projects like FUSE are able to present so many kinds of things as virtual filesystems at the OS level and again, most applications don't care about the difference.
Depending on your application/hardware/access patterns, it certainly might make sense to substitute local storage with a relational database or with a web service. Alternatively, you might want to wrap an existing FileSystem implementation to inject some application-level knowledge (e.g. local storage, with certain paths or file-types more aggressively cached in memory). Maybe your operating system will do some of that for you, or maybe it won't, or maybe certain systems will do a much better job than others. By bringing that up to the application level, you may be able to achieve more consistent performance across platforms.
There's an argument that they should all should be async (or maybe synchronous at the lowest level, but accessed through a component which performs all operations on a private queue). Unfortunately it's not very convenient to use chains of asynchronous functions in Swift.
So that's a more fleshed-out argument for abstracting the filesystem at the application level. As I said before though, I think discussion about any specific changes to Foundation are not directly relevant to this topic (which was about splitting up the Foundation module).
1 Like