You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on the name pollution issue, I started thinking it could be much tidier if Command "has-a" EventEmitter rather than "is-a" EventEmitter.
I expect the primary use of EventEmitter by clients is for adding .on() callbacks. This could be offered with a delegate routine for just that, and the other EventEmitter functionality done internally using a private property.
Advantages of changing the EventEmitter usage are:
reduce noise in code completion suggestions in editors
reduce name collisions when storing option values as properties on Command
if clients do not need access to EventEmitter, can remove implicit dependency on TypeScript definitions for node
Do any gentle readers use more than .on() from EventEmitter?
Do you rely on this being the command object in your listener?
The text was updated successfully, but these errors were encountered:
While working on the name pollution issue, I started thinking it could be much tidier if Command "has-a" EventEmitter rather than "is-a" EventEmitter.
I expect the primary use of EventEmitter by clients is for adding
.on()
callbacks. This could be offered with a delegate routine for just that, and the other EventEmitter functionality done internally using a private property.Advantages of changing the EventEmitter usage are:
Do any gentle readers use more than
.on()
from EventEmitter?Do you rely on
this
being the command object in your listener?The text was updated successfully, but these errors were encountered: