Add File.writeAsLines/writeAsLinesSync methods

[jamesderlin]

File has readAsBytes and writeAsBytes, readAsString and writeAsString, and readAsLines but no corresponding writeAsLines.

It might seem like it'd be trivial to instead use writeAsString(lines.join('\n')). However:

1. The output from writeAsString(lines.join('\n')) might not technically qualify as a "text file" according to the POSIX definition. POSIX defines a "text file" to be a collection of lines, and a line is defined as having a newline terminator. (Also see https://unix.stackexchange.com/questions/446237/ and https://stackoverflow.com/questions/729692/.)

2. If writeAsLines would be considered trivial, then the same argument could have applied to readAsLines. (For similar reasons regarding a final newline, readAsLines is not quite the same as readAsString().split('\n').) Arguably it's more important for reading to be tolerant and for writing to be strict, which implies that there should be a standard way of writing text files.

(I know I'm being pedantic; I'm not particularly optimistic about this being addressed.)

[lrhn]

The writeAsLines functionality can be achieved by doing:

var out = file.openWrite();
for (var line in lines) out.writeln(line);
out.close();

so the need for a single writeAsLines(List<String> lines) method isn't as great.

For readAsLines, there is no corresponding readln method on the input. You would have to read the input and manually split it, and for asynchronous reading, you would have to combine chunks correctly and then split on some choice of line terminators. It's just more complex to read than to write.

Admittedly, writeAsString is also just file.openWrite()..write(string)..close(); and writeAsBytes is file.openWrite()..add(bytes)..close();, so that's not much of an argument.
It's more likely that the need for the use-case just wasn't obvious to the original designers.

Adding any method to any interface is currently a breaking change, so adding the method will probably only happen if we consider having it worth the cost. With the rather easy workaround above, I wouldn't be too optimistic either.

If we ever rework the dart:io API, it's worth remembering this.

[sigurdm]

Adding any method to any interface is currently a breaking change,

But it could be done as an extension?

[lrhn]

Sure. I'm not particularly fond of simply adding extensions methods for anything that we might want to add to an API that we control ourselves.
It means that some methods are instance methods and other methods are extension methods, and the only real reason for the difference is "added before/after 2.0". That's not good design.

(Now, if we had interface default methods, I'd be much happier adding some of those, and changing existing methods to be such, because that would be a backwards and forwards compatible change where all the methods are still instance methods).

[sigurdm]

That's not good design.

I follow the sentiment.
Question is how important 'clean' design is vs. how useful our standard libraries are.

We did not have extensions before 2.x. One could argue that writeAsString should also be an extension as it should (always?) be implemented in terms of other primitives from File. As such it is a disadvantage that writeAsString is an instance method - but that is too late to change.

Are there technical disadvantages to writeAsLines being an extension method, besides revealing our lack of foresight?

Now, if we had interface default methods...

I had not heard of these before. Is there a proposal for this already?

[lrhn]

Not a proposal as such, but there is a request.
(And I have a proposal written, just haven't uploaded it yet).