Add GroupSet and SetGroup classes.

lib/src/set_group.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 'group_set.dart';
+import 'wrappers.dart';
+
+/// A set of sets that provides a view of the union of those sets.
+///
+/// This is a convenience class for creating a [GroupSet] whose contents change
+/// over the lifetime of a class. For example:
+///
+/// ```dart
+/// class Foo {
+///   Set<String> get contents => _contentsGroup.set;
+///   final _contentsGroup = new SetGroup<String>();
+///

[Lasse Reichstein Nielsen, 2016/04/12 13:55:22]

I can't figure out when I would use this class, and the example doesn't help me.
Can you expand on the example?

Is it really just a shorthand for:

  var sets = new Set<Set<E>>();
  var set = new GroupSet<E>(sets);

where you make "set" a getter on sets so you can pass it around as one value
instead of as two?

If so, I think it's too specialized to warrant a separate class, and extending
the Set<Set<E>> interface is something I'd try to avoid. I'd rather have a
"SetGroup" which is a pair of Set<Set> and GroupSet, and not embed one of them
in the other and invent a new almost-set interface.

[nweiz, 2016/04/12 20:29:20]

Done.

[nweiz, 2016/04/13 00:00:57]

After making the change and trying it out, I remembered why this is important:
the code snippet you wrote doesn't work. One instance variable can't refer to
another in its initializer, so "new GroupSet(sets)" doesn't work. We need some
sort of utility class to gracefully initialize this.

I've expanded the example to be a little clearer about how this is supposed to
be used. I think it does make sense to have this implement Set<Set<E>> directly.
I'm thinking of it as an analogue to StreamGroup or FutureGroup in the async
package, which are in turn analogues to StreamController and Completer: they're
"backend" classes that provide an API for controlling the behavior of a
"frontend" class that's exposed to the user. Set APIs like add() and remove()
are part of that backend API.

If you think it's too weird to expose the full set API, I'd rather just support
add() and remove() explicitly. This seemed needlessly limited to me, but I think
it's a better API than requiring users to write "group.components.add" or
whatever.

+///   // ...
+/// }
+/// ```
+class SetGroup<E> extends DelegatingSet<Set<E>> {
+  /// The [GroupSet] that provides a view of the union of sets in [this].
+  GroupSet<E> get set => _set;
+  GroupSet<E> _set;
+
+  SetGroup() : super(new Set<Set<E>>()) {
+    _set = new GroupSet<E>(this);
+  }
+}