I really really like .pipe() of the stream-interface, not just for netsockets or diskwrites/reads, but also for streams of data in general.
A silly example to illustrate: numberGenerator.pipe(fibonacciNumberDetector) fibonacciNumberDetector.pipe(primeNumberDetector) primeNumberDetector.pipe(aStreamThatNeedsPrimeFibonacciNumbers) It is very easy to tell what is going on and what the result should look like. Or, maybe, see this gist for a more practical example: https://gist.github.com/2521280 Parse a stream of JSON data, join the streams of the previously parsed objects into another stream and finally filter objects out of the joining stream into another stream. No joke, if you'd tell me right now that streams .pipe() will save the world, I would believe it; At least for a couple of seconds. On Sat, Apr 28, 2012 at 8:09 PM, Isaac Schlueter <[email protected]> wrote: > On Sat, Apr 28, 2012 at 10:42, Glenn Block <[email protected]> wrote: >> So given the case of a multi-step process where each step needs to be >> performed async you would recommend callbacks/named callbacks right? > > If each step is independent of each other step, then callbacks are fine. > > obj.doThing(function (er, ok) { > // ok, done now > obj.doAnotherThing(function (er, ok) { > // done with the other thing now > }) > }) > > is a bit more humane than: > > obj.doThing() > obj.once("didthing", function () { > obj.doAnotherThing() > obj.once("didanotherthing", function () { > > > That being said, the most common use case for event emitters in node > is when there's exactly one listener. That's why we optimize the hell > out of that case. It's perfectly fine to use them in cases where > there'll be one listener. The relevant difference is if the event > setup and the method call are separate from one another conceptually. > > A callback is "Do X and then when it's done, let me know". An event > is "Any time X happens, let me know", which may be triggered by some > other thing somewhere else in teh program doing something. > > > On Sat, Apr 28, 2012 at 11:02, Mark Volkmann <[email protected]> > wrote: >> On Sat, Apr 28, 2012 at 9:07 AM, Tim Caswell <[email protected]> wrote: >>> A stream is some query that emits a finite stream of data. >> So do we have agreement that if a stream never emits an "end" event >> then something went wrong and this is never intentional? Maybe this is >> one criteria for choosing between EventEmitter and streams. Choose >> EventEmitter when there is no guaranteed end of data. > > No. Streams are not necessarily finite. Consider the case where you > have a video camera streaming data. You might have a stream of mpeg > chunks or something, but it won't necessarily end (unless someone > shuts off the video camera.) Or even simpler, say you have a TCP > connection from one server to another. Under normal circumstances, > that connection might not be severed for days, or years, or longer. > > The finiteness of a Stream is determined by the thing it represents, > not by anything essential to the abstraction. > > Choose Streams when it is a stream of buffers and strings that you > need to be able to pause and resume, as in the case of TCP > backpressure. > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Oliver Leics @ G+ https://plus.google.com/112912441146721682527 -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
