Implement File.{readAsBytes, readAsText, readAsLines}.

Implement File.{readAsBytes, readAsText, readAsLines}.

Convenience methods to use if all you care about is getting the
entire contents of a file.

R=sgjesse@google.com
BUG=1579
TEST=standalone/FileTest

Committed: https://code.google.com/p/dart/source/detail?r=4568

[Søren Gjesse, 2012-02-24 07:24:51]

lgtm, with suggestions

http://codereview.chromium.org/9452014/diff/1/runtime/bin/file_impl.dart
File runtime/bin/file_impl.dart (right):

http://codereview.chromium.org/9452014/diff/1/runtime/bin/file_impl.dart#newc...
runtime/bin/file_impl.dart:834: var chunks = [];
We have the class _BufferList in runtime/bin.

var chunks = new _BufferList()
chunks.add(...)
chunks.add(...)
...
List<int> all = chunks.readBytes(chunks.length);

http://codereview.chromium.org/9452014/diff/1/tests/standalone/src/FileTest.dart
File tests/standalone/src/FileTest.dart (right):

http://codereview.chromium.org/9452014/diff/1/tests/standalone/src/FileTest.d...
tests/standalone/src/FileTest.dart:907: static void testReadAsText() {
I know that the decoders are tested elsewhere, but maybe we should add a test
file with some non-ascii text and test reading that as both UTF-8 and ISO-8859-1
and observe the difference.

http://codereview.chromium.org/9452014/diff/1/tests/standalone/src/FileTest.d...
tests/standalone/src/FileTest.dart:931: static void testReadAsLines() {
Again I know that the line-splitting is tested elsewhere, but maybe we should
have a multiline test text file

[Mads Ager (google), 2012-02-24 13:11:17]

http://codereview.chromium.org/9452014/diff/1/runtime/bin/file_impl.dart
File runtime/bin/file_impl.dart (right):

http://codereview.chromium.org/9452014/diff/1/runtime/bin/file_impl.dart#newc...
runtime/bin/file_impl.dart:834: var chunks = [];
On 2012/02/24 07:24:51, Søren Gjesse wrote:
> We have the class _BufferList in runtime/bin.
> 
> var chunks = new _BufferList()
> chunks.add(...)
> chunks.add(...)
> ...
> List<int> all = chunks.readBytes(chunks.length);

Done.

http://codereview.chromium.org/9452014/diff/1/tests/standalone/src/FileTest.dart
File tests/standalone/src/FileTest.dart (right):

http://codereview.chromium.org/9452014/diff/1/tests/standalone/src/FileTest.d...
tests/standalone/src/FileTest.dart:907: static void testReadAsText() {
On 2012/02/24 07:24:51, Søren Gjesse wrote:
> I know that the decoders are tested elsewhere, but maybe we should add a test
> file with some non-ascii text and test reading that as both UTF-8 and
ISO-8859-1
> and observe the difference.

Done.

http://codereview.chromium.org/9452014/diff/1/tests/standalone/src/FileTest.d...
tests/standalone/src/FileTest.dart:931: static void testReadAsLines() {
On 2012/02/24 07:24:51, Søren Gjesse wrote:
> Again I know that the line-splitting is tested elsewhere, but maybe we should
> have a multiline test text file

Done.

[Bob Nystrom, 2012-02-24 18:10:10]

Drive-by comment: it seems to me like all of these would be more pleasant to use
if they returned futures instead of requiring the user to assign to a setter:

var foo = new File('foo.txt');
foo.readAsTextHandler = (text) {
  print(text);
}
foo.readAsText();

versus:

new File('foo.txt').readAsText().then((text) {
  print(text);
}

The future code is shorter and naturally flows from left to right (you indicate
the operation first and then specify what you do with the result). In general, I
find the "handler" pattern that the IO libraries use confusing. What would
happen if I did something like:

var foo = new File('foo.txt');
foo.readAsTextHandler = (text) {
  print(text);
}
foo.readAsBytes(); // <- not text

Is the motivation behind the handlers documented somewhere?

[Mads Ager (google), 2012-02-27 08:34:35]

On 2012/02/24 18:10:10, Bob Nystrom wrote:
> Drive-by comment: it seems to me like all of these would be more pleasant to
use
> if they returned futures instead of requiring the user to assign to a setter:
> 
> var foo = new File('foo.txt');
> foo.readAsTextHandler = (text) {
>   print(text);
> }
> foo.readAsText();
> 
> versus:
> 
> new File('foo.txt').readAsText().then((text) {
>   print(text);
> }
> 
> The future code is shorter and naturally flows from left to right (you
indicate
> the operation first and then specify what you do with the result). In general,
I
> find the "handler" pattern that the IO libraries use confusing. What would
> happen if I did something like:
> 
> var foo = new File('foo.txt');
> foo.readAsTextHandler = (text) {
>   print(text);
> }
> foo.readAsBytes(); // <- not text
> 
> Is the motivation behind the handlers documented somewhere?

The motivation for the handlers is only documented in various mail threads. The
motivation is that we need repeated data events for the streaming APIs. In order
to keep the interfaces consistent we are sticking with the events and handlers
for now.

The handlers is a fairly low-level API on top of which it is easy to build other
abstractions later on. As an example, futures are easy to build on top of this.

Similarly, if we want a different style of event-handler registration, that
should be a fairly simple change as well. We could move to "file.on.readAsText =
...;" later on.