Add a bunch of delegates for dart:async types.

lib/src/delegate/stream_controller.dart

+// Copyright (c) 2015, 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.
+
+library async.delegate.stream_controller;
+
+import 'dart:async';
+
+import 'stream_sink.dart';
+
+/// Simple delegating wrapper around an [StreamController].

[Lasse Reichstein Nielsen, 2015/07/02 09:38:39]

I'm not sure I'd consider StreamController an interface at the same level as the
other ones here. It's more like an implementation class. It's "interface" is
StreamSink, and then it has some convenience methods on top.

For the same reason, I don't think I have made any methods expecting a
StreamController as argument - they always expect a StreamSink, which is the
more general type.

If we treat it as an interface, then other classes might start to implement it,
and I wouldn't encourage that.

[nweiz, 2015/07/06 20:40:30]

I don't think of this as a way for otherwise non-controllery classes to
implement StreamController as much as a way for people to implement
StreamControllers with custom functionality. For example, I plan to create a
ForwardingStreamController class that controls a stream while also forwarding
events from another stream, so you can do things like forward a stream but close
it at your discretion.

[Lasse Reichstein Nielsen, 2015/07/07 10:32:18]

I'm not sure I would encourage an extended StreamController for something like
that. It's still using StreamController as if it is a useful interface, and not
just a hodge-podge of functionality thrown together to solve a single problem -
interacting with a stream subscription.

I'd rather either have a new specialized API for your forwarding stream class
with just the methods that makes sense for that, or something that exposes a
StreamController (or StreamSink) rather than *being* one ("favor composition
over inheritance", etc.). 

I also think it was a mistake to make StreamController be a StreamSink to being
with - it should have had an "asStreamSink()" method that returned a wrapper,
keeping the plain interface simpler.

Basically, some classes are intended as interfaces and others are not, and I
worry about blurring the lines. StreamController is in the not-interface group,
which means that code should generally not use it as an interface.
If it matters that ForwardingStreamController implements StreamController, then
it is being used as an interface. If you care about wrapping it and the result
being a StreamController, then it is being used as an interface.

I'd still prefer not to have the wrapper class.

[nweiz, 2015/07/07 21:51:59]

I think there's documentary value in sharing an interface with
StreamController—if a new class would have the same functionality anyway,
sharing an interface makes it very clear that it can be accessed in the same way
as the old class.

That said, you're probably right that a StreamController probably isn't
something people should be wrapping in general, so I'll remove the delegate.

+///
+/// Subclasses can override individual methods, or use this to expose only the
+/// [StreamController] methods of a subclass.
+///
+/// Note that [sink] will provide a sink view of the delegating controller,
+/// rather than of the underlying controller.
+class DelegatingStreamController<T> implements StreamController<T> {
+  final StreamController _controller;
+
+  Future get done => _controller.done;
+
+  bool get hasListener => _controller.hasListener;
+
+  bool get isClosed => _controller.isClosed;
+
+  bool get isPaused => _controller.isPaused;
+
+  StreamSink<T> get sink => new DelegatingStreamSink<T>(this);
+
+  Stream<T> get stream => _controller.stream;
+
+  /// Create a delegating controller forwarding calls to [controller].
+  DelegatingStreamController(StreamController controller)
+      : _controller = controller;
+
+  void add(T data) => _controller.add(data);
+
+  void addError(error, [StackTrace stackTrace]) =>
+      _controller.addError(error, stackTrace);
+
+  Future addStream(Stream<T> stream, {bool cancelOnError: true}) =>
+      _controller.addStream(stream, cancelOnError: cancelOnError);
+
+  Future close() => _controller.close();
+}