First crack at a Streams proposal

Tab Atkins Jr. jackalmage at
Mon Apr 15 17:11:46 PDT 2013

On Mon, Apr 15, 2013 at 5:03 PM, Jake Verbaten <raynos2 at> wrote:
>> I think all of these are only suited for single-consumer streams.  My
> original proposal is explicitly for multi-consumer streams, as I
> designed it explicitly for DOM use-cases that I ran into.
> Most streams I've used have been single consumer streams. Whether I write
> FRP style programs with Signals or whether I write IO programs with streams
> the multi consumer use case comes up less.
> A far more regular case I have is a single "sink" consuming from multiple
> inputs in parallel due to some kind of merge(manyStreams) => stream
> function.

That's the Stream#then method.  Just make a stream of stream-likes,
and call .then() to flatten them into a single output stream.

> The most common use-case for multiple consumers is a second consumer for
> printing / inspection purposes, but that is trivial to model as a map
> function that logs the value and returns it.
> You may want to ask other's who have used Stream like abstractions how
> common the multiple consumer case is.

In the DOM, multi-consumer is the default case, for the same reason
you can register multiple listeners for any event.  Futures were
designed to be multi-consumer for the same reason.


More information about the es-discuss mailing list