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 <i...@izs.me> wrote:
> On Sat, Apr 28, 2012 at 10:42, Glenn Block <glenn.bl...@gmail.com> 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 <r.mark.volkm...@gmail.com>
> wrote:
> > On Sat, Apr 28, 2012 at 9:07 AM, Tim Caswell <t...@creationix.com> 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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> 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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
