Repository navigation
Introduce EventEmitter#listenerCount and deprecate EventEmitter.listenerCount #734
Description
Activity
I'm not aware of the history that led into this, but I'd like to see an addition like this and deprecation of
EventEmitter.listenerCount(..). A static-style function such as this doesn't belong in an API that is built around prototype'd methods. 👍 from me.The history is that because people inherit from
EventEmitterit was decided that we wouldn't screw with any additional prototype properties. My original PR forlistenerCount()was on the prototype, but that was shut down.Reacted by Namgyu Ho@trevnorris can you link to the original discussion? I couldn't find it.
@Fishrock123 First conversation: http://logs.nodejs.org/libuv/2013-03-01#22:49:38.745 (notice that at that time it was called
listenerLength) and a follow up: http://logs.nodejs.org/libuv/2013-08-12#12:12:50.802Ok, I don't see any discussion on why it shouldn't / couldn't be on the prototype though. (Which was what I was hoping for haha)
22:50:32 <isaacs> bnoordhuis: otoh, API is "locked", and people raise holy hell when we add fields to EE 22:50:39 <bnoordhuis> exactly 22:50:48 <bnoordhuis> i don't think new fields are really an option at this time 22:50:59 <isaacs> bnoordhuis: are you saying, not even underscored? 22:51:14 <isaacs> hm. we can put it on the root events object. 22:51:17 <bnoordhuis> well no, because people use underscored properties themselves 22:51:17 <isaacs> or EventEmitter class 22:51:27 <isaacs> EventEmitter.listenerLength(emitter) 22:51:37 <bnoordhuis> yes, namespaced off somewhere safeBasically people add all sorts of things to the EventEmitter prototype, and adding something could break user-land code.
Has anyone done even a cursory check to see what level of conflicts would arise with listenerCount on the prototype? It's crazy to think we could never ever iterate and improve an API once it's released just because people inherit from it.
@jasonkarns no, that's in progress but nobody has done something like that on EE afaik (@Fishrock123?). I agree that it's crazy - but only because we allow additions for other inheritable objects, with EE being the only exception.
I've raised an issue about this, asking for clarification: nodejs/dev-policy#76
@trevnorris Atm the Events API is not stated as being «Locked», btw.
@ChALkeR And underscored methods are "private", but doesn't prevent us from reverting changes b/c the community abuses it. ;-P
Done in 8f58fb9
The
listenerCountmethod was introduced (75305f3) for performance reasons afterEventEmitter#listenersstarted to return a copy of the listeners array (nodejs/node-v0.x-archive#3442). It was added as a static method because of problems with backwards compatibility when thedomainfield was introduced toEventEmitter(nodejs/node-v0.x-archive#5310).Now that we are somewhat less strict about this and is introducing other new methods (2931348) on the prototype for
EventEmitter, maybe we could clean up this api?(You guys who was involved in this, feel free to correct me on the historical details)