Improve EventEmitter documentation

[ibc]

Currently:

emitter.listenerCount(type)
type Value The type of event

emitter.listeners(event)
Returns a copy of the array of listeners for the specified event.

In both cases, type and event arguments refer to the "event name", so I suggest calling both "type".

[targos]

+1 for consistency but I would go with event because it's the name used for the other methods (addListener, emit, ...).
Would you mind creating a PR to address this ?

[ibc]

Wow, I've forked the project and it found that it already uses event instead of type... :)

However I've sent a PR improving it a bit.

[chrisdickinson]

I've been leaning towards the term "topic" since "event" can mean both the name of the event and the actual occurrence of the event.

[mscdex]

"topic" to me sounds like something that involves a 2+-way conversation or something, when in this case it's a one-way thing. Maybe just use "event name?"

[sam-github]

fwiw, "event name" in text makes sense to me, event in the API signature makes more sense to me:

In order to listen for the exit event, call process.on(event) with the event being the "exit" string.

Seems symmetrical and consistent - we call it the exit event, and we set the event argument to the string 'exit'. "topic" is just a word that doesn't show anywhere else in conversation about the event emitter or docs, so doesn't seem to help a lot (to me).

[ibc]

The DOM exposes a Event class/object to the user, but Node's EventEmitter does not. Instead EventEmitter just mentions:

• listener (a function callback)
• event (the name of the event)

Nothing else. And since there is no "Event" object at all it is 100% safe to use event as a simple string, because there is not anything else in the API.

[ryansobol]

+1 for event. It seems pretty harmless to change it in the future if an Event class/object is ever added to the API.

[jasnell]

This can be closed. The documentation has been updated to use eventName consistently