OK so really what you are saying is if you feel more comfortable using callbacks no problem doing that, but event emitters are totally suitable for this.
perf wise, is there a significant difference between the two approaches? How much do you pay for emitting an event over just invoking a callback or vice versa? On Sat, Apr 28, 2012 at 11:09 AM, 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 > -- 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
