First crack at a Streams proposal
Tab Atkins Jr.
jackalmage at gmail.com
Mon Apr 15 19:11:24 PDT 2013
On Mon, Apr 15, 2013 at 5:34 PM, Jake Verbaten <raynos2 at gmail.com> wrote:
> So one thing that is confusing is that `next()` has an API that looks like
> the stream is a "pull stream". A "pull stream" means that you call next()
> and it will give you the next value when it has it. This type of stream
> generally buffers values internally and only gives you them when you pull
> them out by calling next(). Node's streams2 API has a similar thing with a
> read() API.
> The semantics of the stream are actually push, which means the stream will
> just push values out whenever it has them and it's the consumers
> responsibility to add listeners using `listen()`. The usage of `next()` is
> confusing as it's easy to mistake the stream for being pull based.
Ah, I see the problem.
Yes, under my proposal's semantics, you shouldn't be using `next` as
the standard way to consume data - that's what `listen` is for.
`next` is for when you just need the next update only (or the next
update that satisfies some filter) - it imposes no constraints on the
stream, so it's possible to miss updates even if you call `next` again
inside the future's accept callback.
For an example of where this is useful, check out my Font Futures
proposal at <http://www.xanthir.com/b4PV1>. The `FontList#ready`
function is *basically* equivalent to getting an observer stream off
of the loadStatus attribute, and then calling `next("loaded")` on it.
All you care about is the *very next* time it's "loaded" - if it flips
between "loading" and "loaded" more, you don't really care.
(Actually, to handle this properly you need a Stream subclass that
remembers the stream's last update, and a `value` method that's
identical to `next` except it first checks against the last update.)
My proposal isn't meant to be a lossless stream, though like I said,
it's not hard to imagine a subclass that represents one, and a method
that generates a lossless stream out of a lossy stream via buffering.
More information about the es-discuss