Re:The bigger the interface, the weaker the abstraction
by Too on Sunday July 30, 2023 @01:47AM
(#36928240)
In this case, isn't it kindof right though? If it says it represents a file descriptor, not a concrete file. The descriptor reads the file for you. You close the descriptor, not the file, etc. Though in that case you could argue the name of the object should be FileDescriptor and not File. You are onto something, often we model functions to act on objects, not objects to be tools acting on other objects.
[ Parent
| on HN ]
Re:The bigger the interface, the weaker the abstraction
by jonahx on Sunday July 30, 2023 @02:28AM
(#36928442)
Here's some example C using one:
bytesRead = read(fd, buf, BUF_SIZE - 1)
You read the from the file descriptor into the buffer. Just like in Go you read from a file into a byte array. Neither the file descriptor nor the file is conceptualized as a tool for reading. The file descriptor is merely an abstraction of the file, which extends the concept of "file" to include pipes, sockets, and other io.
Re:The bigger the interface, the weaker the abstraction
by tsimionescu on Sunday July 30, 2023 @05:19AM
(#36929368)
In typical OS definitions, a file descriptor or file handle doesn't do anything, it's just some abstract way of referring to a position in a file uniquely. You can ask the OS to read data from the position in the file that the file descriptor points to, or to write data to it, or to map a segment of it into your memory, or to tell you other details about the file. But the file reader, and the file writer, and the file mapper etc are all parts of the OS, not the file nor the file descriptor.
In this sense, the GP is right - to respect OS terminology, in Go we should write
fileReaderWriter := os.Open(path, "rw")
Since os.Open doesn't return a file handle/descriptor, but an object capable of reading or writing to a file. This is different from C, where open() does return a FILE*, which is just a handle to a file which you explicitly pass to read() or write() or mmap() etc.