Use streams because this is literally just a stream recreation

[miyoyo]

Since streams are backed by the VM, they're even faster.

[xenoken]

Hey @miyoyo! Thank you very much for your interest and for your pull request. I was already working on a new stream-based implementation, and now it is available in the master branch.

[miyoyo]

Thanks, I'll still put my approach forward for a few reasons:

0. Your current implementation is broken, creating a broadcast stream listens to the first stream. Fetching anything a second time breaks the code.

1. The send API was broken without bumping a major revision, this is terrible form on pub.
   Even if you don't accept my pull request, I STRONGLY encourage you to repost the original as 1.0.4, then repost the current version as 2.0.0, and annotate the differences explicitly

  static void send<T>(T message) {
    _mainstream.add(message);
  }

vs

  static bool send<T>(T message) {
    final target = _instances[T];
    target?.add(message);
    return target != null;
  }

2. Superfluous streams are created multiple times

  static fetch<T>(Function(T arg) func) {
    if (!_streams.containsKey(T)) {
      _streams[T] = _mainstream.stream
          .asBroadcastStream() // This creates a new stream controller
          .where((event) => event is T) // This too
          .cast<T>(); // So does this
    }

    _streams[T].listen((event) {
      func(event);
    });
  }

3. Code that does more, is slower. With the latest patch I submitted to this pull request, even with send returning a bool, it is significantly faster

This is the test rig used for both versions

  final s = Stopwatch();
  final loops = 1000000;
  var target = 0;
  final complete = Completer<void>();
  s.start();
  A.fetch((int i) {
    target++;
    if (target >= loops) {
      complete.complete();
    }
  });
  for (var i = 0; i < loops; i++) {
    A.send(0);
  }
  await complete.future;
  s.stop();
  print("A done: ${s.elapsedMicroseconds}, at ${s.elapsedMicroseconds / loops} per loop on average");

I/flutter ( 6897): A done: 2636963, at 2.636963 per loop on average
I/flutter ( 6897): B done: 3089097, at 3.089097 per loop on average

Where A is this pull request, and B is the current master.
Keep in mind this is only with a single listener, which, while nearly insignificant for this pull request (Map doesn't slow down a lot as it gets bigger), Your approach requires that at least two streams per listener be hit for every single message created (First is the broadcast stream, second is the casting stream) making the performance significantly worse as more listeners come.

[xenoken]

Thanks for your insights. Based on your feedback, I made some edits to the code.