Introduce EventEmitter#listenerCount and deprecate EventEmitter.listenerCount

[tellnes]

The listenerCount method was introduced (75305f3) for performance reasons after EventEmitter#listeners started 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 the domain field was introduced to EventEmitter (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)

[brendanashworth]

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.

[trevnorris]

The history is that because people inherit from EventEmitter it was decided that we wouldn't screw with any additional prototype properties. My original PR for listenerCount() was on the prototype, but that was shut down.

[Fishrock123]

@trevnorris can you link to the original discussion? I couldn't find it.

[trevnorris]

@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.802

[Fishrock123]

Ok, 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)

[trevnorris]

@Fishrock123

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 safe

Basically people add all sorts of things to the EventEmitter prototype, and adding something could break user-land code.

[jasonkarns]

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.

[brendanashworth]

@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

[ChALkeR]

@trevnorris Atm the Events API is not stated as being «Locked», btw.

[trevnorris]

@ChALkeR And underscored methods are "private", but doesn't prevent us from reverting changes b/c the community abuses it. ;-P

[Fishrock123]

Done in 8f58fb9