I think what you guys are missing is that no one said these are event
emitters. They extend event emitters to provide a new pattern for register
sync/async handlers. Of course if the EventEmitter object changes in core,
EventFlow will have to adapt .. and thats what tests are for.
> What if something went wrong and the event never "ping back"?
This is no different than any other callback. If your callback never gets
called.. of course you are screwed... and you the programmer screwed up.
Not really interested in getting into the usual async flame-war here.
Either you find the lib useful or you dont. I love it and it makes some
patterns that I use really easy to implement. Happy to get constructive
feedback but if you think the approach is an 'abuse', dont use it :)
On Wednesday, January 16, 2013 10:11:16 PM UTC-5, Raynos wrote:
>
> The event interface is simple.
>
> I module X emit an event. module Y listens to the event and does something.
>
> module Y does NOT in whatever way or form return a value from the event.
> Event emitters are not a bidirectional communication channel. They are a
> single direction communication channel.
>
> module Y does NOT return a value or an error through a callback you emit
> on the event. Doing so is doing RPC. `foo.emit("doSomething", data,
> function (err) { ... })` is wrong and should be `foo.doSomething(data,
> function (err) { ... })`
>
> The most important thing is that event emitters is a single direction
> communication. If you want bidirectional communication use a duplex stream
> or functions
>
--
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
