Comment by cableshaft | Hacker News Reader

Comment by cableshaft | Hacker News Reader

Parent Full thread

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+

> 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.)

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. 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...

> 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. 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.

Good to know, thanks :) I've only ever used Python for my own tinkering purposes so I haven't been too aware of any new developments.

But I assume the old ways are still valid code, so if you're working with Python code you may encounter any of now 3 different systems of just navigating paths for file i/o, what the parent claims should be dirt simple.

Yes. It is dirt simple, for dirt simple things. It's quite easy and discoverable from documentation for more complex things.

The method in my link (which changed rather drastically between versions):

- is very much iOS and MacOS specific

- requires knowledge of quite a few iOS/MacOS-related things (FileManager.SearchPathDirectory is probably 80% Apple-specific)

- even though it's a "FileManager", it doesn't even let you access/open a file. You have to perform additional operations on the resulting Directory type (.appendingPathComponent)

- even that doesn't give you a means of opening a file, because in order to read a file, you have to invoke a String constructor. In order to write to a file, you need to invoke a method on a String type. Talk about coupling entirely unrelated things

That is an example of objectively bad API design.

And it's clear from API evolution that it's not even Swift APIs. These are very thin wrappers for OS's existing Obj-C APIs. I think it's the first among languages: to provide OS APIs and call them a standard library for a language. I don't think even MS did that when they were creating .NET.

Microsoft does it all the time with .NET, after all the future of Windows was going to be all .NET.

It just did not worked out that way, as WinDev tanked Longhorn efforts and now we have UWP (aka COM) instead of .NET for OS APIs.

Which are anyway easily accessible from .NET given its COM support.

It is still relatively simple because the conversion between Pathlib<->str is literally one method call (from pathlib, just call `str(pathlib_object)`, from string, just call `pathlib.Path(str_object)`.

I know this because I started a project using only strings and `os.path`, however when testing it started to become complicate to mock the correct paths so in tests I use `pathlib` (with conversions back to string when I finish path manipulation) and the code still works.

    let fileContents = try? String(contentsOfFile: "file.txt")

That works perfectly fine.

In the context of an iOS or MacOS app, that of course won't work, because apps only have access to certain directories. That is why you typically use the FileManager object to get the path to the directory you'll need.

Searching Google for "read file swift" at best returns the StackOverflow answer in my screenshot.

I would never in my life figure out that

- reading from and writing to a file is not the job of file-related modules, but of a string

- that it would just work like this wothout getting a proper handle to the file (what I assumed what the whole FileManager bruhaha was about)

Reply on news.ycombinator.com