0

Consider I want to use EventEmitter2, or some implementation of EventEmitter of my own. However, if I just do EventEmitter = MyEventEmitter, it only helps for explicit inheritance that happens after this declaration, but obviously won't change existing objects inheriting from builtin EventEmitter, and is limited to scope of module.

Can I take advantage of alternative EventEmitters when using builtin objects? I can think of just descending prototype chain of any particular object, and if prototype appears to be instance of EventEmitter, replace it with my own, but isn't there more elegant way?

toriningen
  • 7,196
  • 3
  • 46
  • 68
  • i don't know if this is correct but you shouldn't do that, i believe many core modules or 3rd party modules that use events rely on build-in `EventEmitter` you might break something.. whats is wrong with `var EventEmitter2 = ..` ? – Gntem Apr 06 '14 at 19:03
  • What's the point of custom `EventEmitter`, if you can't use it anywhere? E.g. this brings incosistence — few (yours) objects use custom `EventEmitter` capable of, say, `.many` or event wildcards, and builtin objects use builtin `EventEmitter` that does not expect to deal with `.many`. So, is there any point in custom EventEmitters, if you are the only to use them with your custom API, and others will just stick to good old `on` and `emit`? – toriningen Apr 06 '14 at 22:37
  • Here — http://stackoverflow.com/q/12150540/472695 — in related question the solution is to extend builtin `EventEmitter`'s prototype. But this restricts one to use underlying vanilla implementation, so you have no control about precise structures behind handlers, you cannot, say, implement `on('*')`, because standard `EventEmitter` does not expose convenient ways to do this. I'm fully okay with responsibility to keep it fully backward-compatible in best traditions of duck typing. – toriningen Apr 06 '14 at 22:43

0 Answers0