Consider augmenting EventEmitter about ampersand-events

[wraithgar]

Do you mean adding methods to sync the api with that of EventEmitter, or extending EventEmitter itself? If it's the former that is being discussed in #13. If it's the latter I don't know if it's a good idea as the browserifying of EventEmitter is quite large and unwieldy, last time I checked.

[ianwremmel]

I mostly meant using EventEmitter as a base for ampersand-events. In my experience, EventEmitter is likely to end up in my projects because it's often a dependency of a dependency, so it seemed like a reasonable idea to converge them.

Alternatively, I'd be interested in something like AmpEvents.monkeyPatch(EventEmitter) to bring listenTo and possibly the "all" event to EventEmitter.

All that said, I completely understand if these requests are outside the scope of ampersand, I just wanted to float the idea before attempting to do it.

[wraithgar]

the API for ampersand-events was definitely a direct result of it being a fork of backbone's event API. I think if we add the methods needed to sync at least the methods with that of node's EventEmitter that will go a long way to reducing the mental effort of trying to work in both worlds, especially in the same project.

Gonna go ahead and close this for now, if someone has any good input on the matter feel free to weigh in or even reopen if you think it's warranted.

[ianwremmel]

Follow up question: assuming #14 adds api compatibility with EventEmitter, can/does ampersand-events provide an object that can be used by util.inherits and class X extends EventEmitter as a drop in replacement? I could envision an aggressive webpack config that replaces require('events').EventEmitter with require('ampersand-events').EventEmitter.

[wraithgar]

Unless I'm mistaken this module itself would be the export. The idea is that require('ampersand-events') would have function parity with require('events').EventEmitter

[ianwremmel]

great, I'll give that a try. thanks!