First crack at a Streams proposal
Tab Atkins Jr.
jackalmage at gmail.com
Mon Apr 15 17:11:46 PDT 2013
On Mon, Apr 15, 2013 at 5:03 PM, Jake Verbaten <raynos2 at gmail.com> 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
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