Make Asset.readAsString() async.

Make Asset.readAsString() async.

R=nweiz@google.com

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

[Bob Nystrom, 2013-07-03 00:22:30]

This builds on top of the other barback patch in flight, so you might want to
wait until I've submitted and rebased against that one before you review this.

[nweiz, 2013-07-03 00:48:12]

On 2013/07/03 00:22:30, Bob Nystrom wrote:
> This builds on top of the other barback patch in flight, so you might want to
> wait until I've submitted and rebased against that one before you review this.

You can work around the layering by uploading the baseline patch, then uploading
your change afterwards. That makes it a different patch set, which I can then
review.

[Bob Nystrom, 2013-07-03 17:50:02]

On 2013/07/03 00:48:12, nweiz wrote:
> On 2013/07/03 00:22:30, Bob Nystrom wrote:
> > This builds on top of the other barback patch in flight, so you might want
to
> > wait until I've submitted and rebased against that one before you review
this.
> 
> You can work around the layering by uploading the baseline patch, then
uploading
> your change afterwards. That makes it a different patch set, which I can then
> review.

Good idea. I figured the test patch would land soon anyway, but I'll try that
moving forward.

This patch is rebased now, so review away!

[nweiz, 2013-07-03 18:21:07]

One suggestion, otherwise LGTM.

https://codereview.chromium.org/18478004/diff/4001/pkg/barback/test/utils.dart
File pkg/barback/test/utils.dart (right):

https://codereview.chromium.org/18478004/diff/4001/pkg/barback/test/utils.dar...
pkg/barback/test/utils.dart:415: output += contents;
Doing this imperatively seems less clean than the map/join you were doing
before.

[Bob Nystrom, 2013-07-03 19:44:44]

Committed patchset #2 manually as r24743 (presubmit successful).

[Bob Nystrom, 2013-07-03 19:45:23]

https://codereview.chromium.org/18478004/diff/4001/pkg/barback/test/utils.dart
File pkg/barback/test/utils.dart (right):

https://codereview.chromium.org/18478004/diff/4001/pkg/barback/test/utils.dar...
pkg/barback/test/utils.dart:415: output += contents;
On 2013/07/03 18:21:07, nweiz wrote:
> Doing this imperatively seems less clean than the map/join you were doing
> before.

I know, but Future.forEach() doesn't actually return the resulting futures into
some sequence I can aggregate, and Future.wait() doesn't guarantee ordering. I
think this is about the best I can do.

[nweiz, 2013-07-03 20:11:16]

https://codereview.chromium.org/18478004/diff/4001/pkg/barback/test/utils.dart
File pkg/barback/test/utils.dart (right):

https://codereview.chromium.org/18478004/diff/4001/pkg/barback/test/utils.dar...
pkg/barback/test/utils.dart:415: output += contents;
On 2013/07/03 19:45:23, Bob Nystrom wrote:
> On 2013/07/03 18:21:07, nweiz wrote:
> > Doing this imperatively seems less clean than the map/join you were doing
> > before.
> 
> I know, but Future.forEach() doesn't actually return the resulting futures
into
> some sequence I can aggregate, and Future.wait() doesn't guarantee ordering. I
> think this is about the best I can do.

[Future.wait] had better guarantee ordering; we rely on the ordering all over
the place. We use the pattern of

    Future.wait([future1, future2]).then((results) {
      var result1 = results[0];
      var result2 = results[1];
      ...
    })

very frequently.

[Bob Nystrom, 2013-07-03 20:21:03]

On 2013/07/03 20:11:16, nweiz wrote:
> https://codereview.chromium.org/18478004/diff/4001/pkg/barback/test/utils.dart
> File pkg/barback/test/utils.dart (right):
> 
>
https://codereview.chromium.org/18478004/diff/4001/pkg/barback/test/utils.dar...
> pkg/barback/test/utils.dart:415: output += contents;
> On 2013/07/03 19:45:23, Bob Nystrom wrote:
> > On 2013/07/03 18:21:07, nweiz wrote:
> > > Doing this imperatively seems less clean than the map/join you were doing
> > > before.
> > 
> > I know, but Future.forEach() doesn't actually return the resulting futures
> into
> > some sequence I can aggregate, and Future.wait() doesn't guarantee ordering.
I
> > think this is about the best I can do.
> 
> [Future.wait] had better guarantee ordering; we rely on the ordering all over
> the place. We use the pattern of
> 
>     Future.wait([future1, future2]).then((results) {
>       var result1 = results[0];
>       var result2 = results[1];
>       ...
>     })
> 
> very frequently.

Oh, sorry, yes, of course it does. I was thinking more in terms of:

Future.wait(foo.map(() {
  return new Future().then(() { ...stuff... });
});

In this case, there's no guarantee what order those then bodies will run in.