Type-check event names? about emittery HOT 6 CLOSED

We should enforce only strings.

from emittery.

To avoid name collision if you expect an emitter class to be extended and for event you don't especially need to expose.

For those cases, you can add namespace to the event name, or not expose the emitter, but if it doesn't complicate emitteryinternals, supporting Symbol like EventEmitter would be useful.

from emittery.

This will need to be resolved for #1.

from emittery.

Why not support Symbol?

For #1, it just needs to support event key as an array. Even if the list of event key is provided as a string (e.g.: on('start:*') or on('start:foo start:bar')), it's just a matter of filtering symbol event keys.

from emittery.

Why do you want support for Symbols? How would you use it?

from emittery.

@dinoboff That's a good use-case. I hadn't thought of that.

from emittery.