Re: read_file() why not use "r" and "rb" for the 2nd paramater?
- Posted by DerekParnell (admin) Sep 13, 2009
- 1172 views
Discussion in IRC came up about how read_file() and open() both accept a filename and "mode". Why did we move from the standard when creating read_file. It's understood that read_file() only reads, but we could limit the function to understand "r" and "rb" only mode strings, then working with files, we have a consistent API instead of using open("file.txt", "rb") in one case and another case read_file("file.txt", io:BINARY_MODE).
I suspect that, even though the docs do not list them, it is because there is more than one text mode. I think the goal (paraphrasing Derek, I believe) was to be able to get the same behavior cross platform, regardless of the file:
public enum BINARY_MODE, TEXT_MODE, UNIX_TEXT, DOS_TEXT
Matt
Yes, but there's more to it that also.
The idea I had behind read_file() is to use "BINARY_MODE" when every byte in the file is significant, which is exactly as open( "rb") does. And TEXT_MODE means read the text file, regardless of which OpSys created it and return a standardized '\n' line endings, plus ensure a final line ending. The open("r") does not do that.
When writing files, the write_file() has advantages over open("w"/"wb").
- TEXT_TEXT mode writes the file using the current OpSys standard for line endings.
- DOS_TEXT mode writes the file ensuring DOS line endings are used, regardless of which OpSys runs the function.
- UNIX_TEXT mode writes the file ensuring Unix line endings are used, regardless of which OpSys runs the function.
Besides, the enum names are better for documentation than the "r" and "rb" strings.
