delegating event emitter

287 views
Skip to first unread message

Pedro Teixeira

unread,
Apr 8, 2012, 5:04:04 AM4/8/12
to nod...@googlegroups.com
Delegating an event emitter into another event emitter is hard.

A catch-all event handler that worked like this would be of much help:

eventEmitter.on(function(eventType, args) {
  console.log('got event type %s and args %j', eventType, args);
});

Do you know if something like this is on the works? If not, is this a desirable feature?

Oliver Leics

unread,
Apr 8, 2012, 7:36:35 AM4/8/12
to nod...@googlegroups.com
Have a look at https://github.com/hij1nx/EventEmitter2

eventEmitter.on('*', function() {
console.log('got event type %s and args %j', this.event, arguments);
});

Another way would be to overwrite EventEmitter.prototype.emit

Pedro Teixeira

unread,
Apr 8, 2012, 11:25:45 AM4/8/12
to nod...@googlegroups.com
Yes, thanks, I know that's an option.
Are there any plans to standardize this into core?

> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

Oliver Leics

unread,
Apr 8, 2012, 1:29:07 PM4/8/12
to nod...@googlegroups.com
On Sun, Apr 8, 2012 at 5:25 PM, Pedro Teixeira <pedro.t...@gmail.com> wrote:
> Yes, thanks, I know that's an option.
> Are there any plans to standardize this into core?

Question is, why?

The core EventEmitter-class is pure javascript, nothing fancy, just
the very basics. It is sufficient for almost all situations. The more
you add to this basics, the more overhead/inefficiency you'll get in
return.

If it is really not sufficient, a simple 'npm install eventemitter2'
or dependency to eventemitter2 in package.json , then
require('eventemitter2') - and hooray, and you can use it.

But if I would need only what you described, I would overwrite 'emit'
of the EventEmitter. Its not that hard, EventEmitter of nodes
events.js is pure JS.

Pedro Teixeira

unread,
Apr 8, 2012, 1:59:20 PM4/8/12
to nod...@googlegroups.com, oliver...@gmail.com
Thanks, I know that.

My question still remains:

Are there any plans to support this on Node Core in order to make it standard or does any one has anything to say agains this piece of functionality?

mscdex

unread,
Apr 8, 2012, 3:48:40 PM4/8/12
to nodejs
On Apr 8, 1:59 pm, Pedro Teixeira <pedro.teixe...@gmail.com> wrote:
> Are there any plans to support this on Node Core in order to make it
> standard or does any one has anything to say agains this piece of
> functionality?

I haven't looked closely at other features of EventEmitter2 and
similar modules, but I'd have an issue with how EE2 implements their
"catch-all" event (reserving "*" as a special event name). I'd much
rather see a separate method for this instead, such as onAll().

Pedro Teixeira

unread,
Apr 8, 2012, 3:53:49 PM4/8/12
to nod...@googlegroups.com
What about the syntax I proposed? (1st arg is catch-all callback).

Oliver Leics

unread,
Apr 8, 2012, 3:57:52 PM4/8/12
to nod...@googlegroups.com
I seriously wonder if you read what I wrote.

No offense.

Pedro Teixeira

unread,
Apr 8, 2012, 4:03:04 PM4/8/12
to nod...@googlegroups.com
I did.
I understand your view and that it could be problematic adding that
into the Event emitter critical path of emit(), but I think we could
easily work around that.

I'm interested here in collecting opinions and also from the core team.

No dia 08/04/2012, às 20:58, Oliver Leics <oliver...@gmail.com> escreveu:

> I seriously wonder if you read what I wrote.
>
> No offense.
>

Oliver Leics

unread,
Apr 8, 2012, 4:04:45 PM4/8/12
to nod...@googlegroups.com
On Sun, Apr 8, 2012 at 9:48 PM, mscdex <msc...@gmail.com> wrote:
> I haven't looked closely at other features of EventEmitter2 and
> similar modules, but I'd have an issue with how EE2 implements their
> "catch-all" event (reserving "*" as a special event name). I'd much
> rather see a separate method for this instead, such as onAll().

EventEmitter2 has .onAny()

Ben Noordhuis

unread,
Apr 9, 2012, 3:34:26 AM4/9/12
to nod...@googlegroups.com, oliver...@gmail.com
On Sun, Apr 8, 2012 at 19:59, Pedro Teixeira <pedro.t...@gmail.com> wrote:
> Are there any plans to support this on Node Core in order to make it
> standard

No.

Marco Rogers

unread,
Apr 9, 2012, 6:24:09 PM4/9/12
to nod...@googlegroups.com
There was a very long and heated debate about this last year sometime. I can't find it right now. I believe it was split between pull request comments and a thread on the mailing list. Things were pretty split on whether we wanted to greatly expand the scope of EventEmitter, by merging in some of the features of EventEmitter2, or whether we wanted a very minimal catch all api, that would enable many other things to be layered on top in user land. Of course there were some that wanted neither.

I would like to have this debate again, hopefully with less arguing and more reason. I really like the one function parameter api. But you have to support the rest of the api. How do you retrieve the list of catch-all listeners? e.g. emitter.listeners('error'). The star syntax is handy here, but if we don't use that we need yet another convention. Pass nothing to emitter.listeners() and it'll return the list of catch-alls? I don't like that. emitter.globalListeners()?

Maybe it's best that we don't dredge up links to prior art as it'll just reignite the old arguments. I really hope that the core team is opening up to these types of improvements again.

:Marco

Oliver Leics

unread,
Apr 9, 2012, 7:32:31 PM4/9/12
to nod...@googlegroups.com
Now available on npm:

caevents - 'Catch all events' event emitter for node.js

npm install caevents

Repository:
https://github.com/oleics/node-caevents

Pedro Teixeira

unread,
Apr 9, 2012, 7:56:34 PM4/9/12
to nod...@googlegroups.com
Actually, the one function parameter api idea I got from @hij1nx some time after the EventEmitter -> Core debate.
Many times I've had the need for something like this, so I think this should be something that others may find an interest on.

I think I'll start by doing a pull request to Node Core, it should be fairly simple to get the discussion going - some time this week. If the core team is reluctant or present fair arguments I'll just roll out my module or extend Oleic's caevents (which is a great start, thanks Oliver).

-Pedro


--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en



--
-Pedro

Marco Rogers

unread,
Apr 9, 2012, 9:38:46 PM4/9/12
to nod...@googlegroups.com, oliver...@gmail.com
Just sent you a quick pull request :)

Marco Rogers

unread,
Apr 9, 2012, 9:42:46 PM4/9/12
to nod...@googlegroups.com
If it helps, here's the super old branch I had when this came up before. I was (still am) a pretty staunch advocate of a minimal catch all.


For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en



--
-Pedro

mscdex

unread,
Apr 10, 2012, 12:44:59 AM4/10/12
to nodejs
On Apr 9, 9:42 pm, Marco Rogers <marco.rog...@gmail.com> wrote:
> If it helps, here's the super old branch I had when this came up before. I
> was (still am) a pretty staunch advocate of a minimal catch all.

FWIW I'd much rather not see any more special/reserved event names.
I'm more in favor of onAny()/onAll(), etc.
Reply all
Reply to author
Forward
0 new messages