5 ms·

The directory thing is more due to sandboxing than anything else. They don't want someone to be able to write an app that can read anything anywhere on your pho

The directory thing is more due to sandboxing than anything else. They don't want someone to be able to write an app that can read anything anywhere on your phone, so it has specific directories that have different levels of access and temporality (i.e. one is a temp folder that gets flushed each time you quit the app, if I remember correctly). It's not that complicated once you look it up, and like most of this stuff, you can mostly write wrapper classes one time to hide the gnarly bits and call your wrapper class to do what you need to do the way you like to do it. It's been several years since I've had it read from a file, and I actually thought I would click that twitter link and see something super complicated, but it's actually pretty straight-forward. Not a one-liner like some languages, no, but as soon as you want to open something with options (like the encoding in this one), most other languages start looking more complicated like this as well. Like python's open looks more like this with options: "open(filename, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)". I've opened many a file in Python scripts, but I'd have to look up buffering, encoding, errors, closefd, and opener right now if I wanted to use them (I haven't really in the past) And Python has 11 different access modes that I often have to look up to remember what all my options are again: r+,w,wb,w+,wb+,a,ab,a+, and ab+

dmitriid 7y ago
> They don't want someone to be able to write an app that can read anything anywhere on your phone, And that's the main problem with Foundation which hurts Swift as a language: it was made for iPhone apps, and hardly anything else. I was trying to make a CLI app on the desktop. I gave up and used something else. > It's not that complicated once you look it up, and like most of this stuff Yeah, I tried to look it up. It's extremely complicated, and it doesn't help that the documentation tends to spread all the knowledge across dozens of pages with very terse documentation and next to zero examples. > I've opened many a file in Python scripts, but I'd have to look up buffering, encoding, errors, closefd, and opener right now if I wanted to use them My example doesn't have any buffering, or encoding, or anything. It's just reading a file. There's no chance in hell you can deduce those lines from the documnentation, or find out where to put the files to read from, or find out that it's not the file's job to read/write data, but String type's (wat?) etc. It doesn't help that the only real example of reading and writing files isn't in the docs, but in a StackOverflow answer (most other examples are either outdated, or use calls to Obj-C libs etc.)
- cableshaft 7y ago
  It sounds to me like you're just asking for a quick and dirty default that's nice and pithy and short. That's fine, but file i/o tends to get messy and easy to exploit without some safeguards, and doing it "right" tends to be a bit more complicated. Like part of your complaint above is pathing, and even something as short and pithy as Python (at least in my opinion, that's why I keep going to it to write proof of concepts), in order to do file i/o "right", requires knowing about all sorts of other things. One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html https://docs.python.org/3/library/os.path.html. Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS. That's not too much different than having to specify a type of directory for Swift, and has the same types of reasons for why it exists, for safety, but it just doesn't let you do something potentially dumb like open('blah.txt') for something quick and dirty, like Python does, which I admit I do abuse if I'm trying to write something quick and dirty myself. EDIT: This link here shows how you can write a helper function to basically turn the file i/o into a 2-liner, and I'm sure there's ways to make this even simpler: https://www.hackingwithswift.com/example-code/strings/how-to-save-a-string-to-a-file-on-disk-with-writeto https://www.hackingwithswift.com/example-code/strings/how-to...
  - m45t3r 7y ago
    > One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html https://docs.python.org/3/library/os.path.html. Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS. There is pathlib nowadays that allows you to navigate in very complex situations using a quite nice OOP API.

dmitriid 7y ago

> They don't want someone to be able to write an app that can read anything anywhere on your phone, And that's the main problem with Foundation which hurts Swift as a language: it was made for iPhone apps, and hardly anything else. I was trying to make a CLI app on the desktop. I gave up and used something else. > It's not that complicated once you look it up, and like most of this stuff Yeah, I tried to look it up. It's extremely complicated, and it doesn't help that the documentation tends to spread all the knowledge across dozens of pages with very terse documentation and next to zero examples. > I've opened many a file in Python scripts, but I'd have to look up buffering, encoding, errors, closefd, and opener right now if I wanted to use them My example doesn't have any buffering, or encoding, or anything. It's just reading a file. There's no chance in hell you can deduce those lines from the documnentation, or find out where to put the files to read from, or find out that it's not the file's job to read/write data, but String type's (wat?) etc. It doesn't help that the only real example of reading and writing files isn't in the docs, but in a StackOverflow answer (most other examples are either outdated, or use calls to Obj-C libs etc.)

cableshaft 7y ago
It sounds to me like you're just asking for a quick and dirty default that's nice and pithy and short. That's fine, but file i/o tends to get messy and easy to exploit without some safeguards, and doing it "right" tends to be a bit more complicated. Like part of your complaint above is pathing, and even something as short and pithy as Python (at least in my opinion, that's why I keep going to it to write proof of concepts), in order to do file i/o "right", requires knowing about all sorts of other things. One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html https://docs.python.org/3/library/os.path.html. Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS. That's not too much different than having to specify a type of directory for Swift, and has the same types of reasons for why it exists, for safety, but it just doesn't let you do something potentially dumb like open('blah.txt') for something quick and dirty, like Python does, which I admit I do abuse if I'm trying to write something quick and dirty myself. EDIT: This link here shows how you can write a helper function to basically turn the file i/o into a 2-liner, and I'm sure there's ways to make this even simpler: https://www.hackingwithswift.com/example-code/strings/how-to-save-a-string-to-a-file-on-disk-with-writeto https://www.hackingwithswift.com/example-code/strings/how-to...
- m45t3r 7y ago
  > One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html https://docs.python.org/3/library/os.path.html. Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS. There is pathlib nowadays that allows you to navigate in very complex situations using a quite nice OOP API.