dart:io should use Futures not "handlers"

[DartBot]

This issue was originally filed by @seaneagan

---

dart:io currently uses "handlers" for async operations instead of the standard Future API. This is inconsistent and less powerful. For example, File could look like:

interface File {
  //...
  Future<void> create();
  Future<void> delete();
  Future<bool> exists();
  Future<String> fullPath();
  Future<RandomAccessFile> open([FileMode mode]);
}

//...

file.exists().then((bool exists) => print(exists ? "yes" : "no"));

// and replace createSync, deleteSync, etc. with issue #104
print(await file.exists() ? "yes" : "no");

[iposva-google]

cc @madsager.
cc @sgjesse.
Added Area-IO, Triaged labels.

[madsager]

I don't think the handlers are any less powerful. In fact I think the handlers is a lower-level API on top of which you can build the Future API if you so desire. See the example below.

Futures is not a good match for the streaming APIs for example. At this point we are keeping the APIs low-level but consistent. The APIs might change but moving to Futures is not a priority at this point.

#import('dart:io');

class FutureFile {
  File _file;
  
  FutureFile(String path) {
    _file = new File(path);
  }
  
  Future<bool> exists() {
    Completer completer = new Completer();
    _file.exists();
    _file.existsHandler = (result) {
      completer.complete(result);
    };
    // TODO: add error handler that completes with an error.
    return completer.future;
  }
}

void main() {
  FutureFile f = new FutureFile('flaf.txt');
  f.exists().then((exists) => print(exists));
}

---

Removed Type-Defect, Priority-Medium labels.
Added Type-Enhancement, Priority-Low labels.

[DartBot]

This comment was originally written by @seaneagan

---

Async method completion (e.g. File#{create,delete,exists,etc.}) should be localized to each call, not set on the File (or similar) objects. Otherwise when you call an async method, you need to check that any previous call has been completed before changing the associated "handler" property to whatever you need for the new call. Thus it cannot be used for concurrent file operations of the same type. One would be forced to use separate File objects for each operation, thus losing any low-level gains from not using Futures, not to mention more verbose and confusing code. The situation is even worse with error handlers being shared across multiple operation types.

Thus, if Futures are too much overhead, the async methods should accept success and (optional) error callback functions. For events which occur multiple times not in response to a particular asyn method call (e.g. lineHandler, dataHandler, errorHandler), however, are correctly placed on the Stream objects, and if full-on Event objects are too much overhead then "handler" properties work just fine there.

[DartBot]

This comment was originally written by amatiasq...@gmail.com

---

Agree with Comment#­3 @­seaneagan1

Good summary.

[madsager]

Added Fixed label.

[kevmoo]

Removed Area-IO label.
Added Area-Library, Library-IO labels.