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?
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
thisbeing the command object in your listener?