Dave Whipp wrote:
Under the hood, I don't really care, as long as it works (and is sufficiently efficient). There are obvious implementations that might be a bit inefficient on the first iteration (e.g. close and reopen). Quite frankly, the number of times I open unstructured files in rd/wr mode in a typical program can be measured on the fingers of one foot! If I want to do a R-M-W operation then I do like -i, and use a tmp file. Maybe the hypothetical TextFile object would do the same (by default). If I want to micromanage the actual access to the file object, then I'd be happy to c<use> a module that lets me manipulate file handles directly. I just don't see that as the common case.
Your case 2 is easy: "my Str $passwds is File("/etc/passwd") is const". With that, we might even catch your error at compile time.
/file/open/ and we're back where we started.
Except that we've lost a layer of abstraction: the programmer manipulates a
file's contents, not its accessor. Text files would be just an
implementation of strings. No need to learn/use a different set of
operators. Want to read bytes: use $str.bytes. Graphemes: $str.graphs. Also,
we use the existing access control mechanisms ("is rw", "is const", instead
of inventing new ones to pass to the C<open> function as named-args).
I think part of the "mental jam" (at least with me), is that the read/write, exclusive, etc, are very critical to the act of opening the file, not only an after the fact restriction on what I can do later. If I cannot open a file for writing (permissions, out of space, write locked, etc), I want to know the instant I attempt to open it as such, _not_ when I later attempt to write to it. Having all these features available to open as arguements seems a much better idea to me. It's "Open a file with these specifications", not "Open a file, and then apply these specifications to it".
I do admit there is merit to your abstraction system, but IMO, it belongs in a library.
-- Rod Adams
