I believe open should accept the mode as a number rather than a string to allow multiple modes to be combined (via bitwise-or). For example, I want to express that I want to open a file to be written, and to be created first, if it doesn't exist, as in O_WRONLY | O_CREAT (where O_WRONLY = 0x1 and O_CREAT = 0x40).
Example:
async function main() {
let file = Deno.open("google.html", Deno.OPEN_WRITE | Deno.OPEN_CREATE);
let conn = await Deno.dial("tcp", "google.com:80");
await conn.write(new TextEncoder().encode("GET /\n"));
return Deno.copy(await file, conn);
}
main();
Edit 1: This would be in line with Go's open flags: https://golang.org/pkg/os/#pkg-constants
Edit 2: If you use "w", currently it will automatically create a new file if it doesn't exist. The point is to make this explicit in the flags. For example, I would expect "w" to fail if the file doesn't exist (since the create flag is not explicit).
The Go open flags are basically the *nix commons.
Another option is to design an OpenOptions similar to the one used by Deno.writeFile: https://deno.land/typedoc/interfaces/deno.writefileoptions.html
I think there's one question regarding the names: Do we use the classic Unix names (for example, O_WRONLY, O_CREAT) or simplified names (for example, write [write_only?], create)?
And the second question: How do we allow multiple flags to be passed to the API? Options object, array spread, or bitmask?
open(file, { write: true, create: true })
open(file, O_WRITE, O_CREATE)
open(file, O_WRITE | O_CREATE)
I think that simple names in combination with an options object are the most idiomatic for JavaScript (though I do also see value in sticking with the actual Unix names and using bitmasks).
open(file, { write: true, create: true })
Seams most reasonable to me
I can鈥檛 find the link but there was a comment from one of the Go people describing regrets in the API and the only one they could come up with was that they hadn鈥檛 renamed these flags...
Most helpful comment
Seams most reasonable to me
I can鈥檛 find the link but there was a comment from one of the Go people describing regrets in the API and the only one they could come up with was that they hadn鈥檛 renamed these flags...