Add sinks to provide synchronous access to events.

lib/src/byte_accumulator_sink.dart

+// Copyright (c) 2016, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+import 'dart:convert';
+import 'dart:typed_data';
+
+import 'package:typed_data/typed_data.dart';
+
+/// A sink that provides synchronous access to the concatenated bytes passed to

[Lasse Reichstein Nielsen, 2016/04/22 09:15:13]

I don't think you need to say "synchronous" here. 
It just provides access to the bytes passed to it so far, and sinks are
generally synhronous (what they do with the input might not be, but the sink
itself is).

[nweiz, 2016/04/22 21:19:56]

Done.

+/// it.
+class ByteAccumulatorSink extends ByteConversionSinkBase {
+  /// The bytes accumulated so far.
+  ///
+  /// This should not be modified, although this restriction isn't enforced.

[Lasse Reichstein Nielsen, 2016/04/22 09:15:13]

More precisely:

The returned `Uint8List` is viewing a shared buffer, so it should not be changed
and any bytes outside the view should not be accessed.

[nweiz, 2016/04/22 21:19:56]

Done.

+  Uint8List get bytes => new Uint8List.view(_buffer.buffer, 0, _buffer.length);
+  final _buffer = new Uint8Buffer();

[Lasse Reichstein Nielsen, 2016/04/22 09:15:13]

Empty line before

[nweiz, 2016/04/22 21:19:56]

Done.

+
+  /// Whether [close] has been called.
+  bool get isClosed => _isClosed;

[Lasse Reichstein Nielsen, 2016/04/22 09:15:13]

As usual I prefer the fields before the getters. It's hard to figure out the
internal state of the class when the fields are spread out between other
members.

[nweiz, 2016/04/22 21:19:56]

I think of fields as a special case of getters, so it makes sense that they're
organized together. I also think of getters as important views into a class's
state; even if they're derived data, they're important enough to be made easily
accessible which means they're relevant to understanding the semantic state of
the object.

Also, when two members are tightly coupled (for example a getter that returns an
unmodifiable view of a field), I find it much clearer to visually group them as
well.

+  var _isClosed = false;
+
+  void add(List<int> bytes) {
+    if (_isClosed) {
+      throw new StateError("Can't add to a closed sink.");
+    }
+
+    _buffer.addAll(bytes);
+  }
+
+  void addSlice(List<int> chunk, int start, int end, bool isLast) {
+    if (_isClosed) {
+      throw new StateError("Can't add to a closed sink.");
+    }
+
+    _buffer.addAll(chunk, start, end);
+    if (isLast) _isClosed = true;
+  }
+
+  void close() {
+    _isClosed = true;
+  }
+}