Implement inversion of control flavors of on(), once(), and off()

[lazd]

This might be outside of the goals of this library (tiny-emitter), but it would be great to see the IoC flavors of the methods:

• on: listenTo
• once: listenToOnce
• off: stopListening

These are incredibly useful for ensuring that all event listeners are cleaned up. For instance, a parent class can call stopListening in its destruct method, ensuring that any event listener added by any child class goes away during destruction.

For further documentation, see the documentation for Backbone's Event mixin.

What do you think?

[scottcorgan]

Sounds like an awesome idea. But, you're right, it's out of the context of this module.

I've never been a fan of inheritance as well. I know how useful it is, but I always found myself choosing composition over inheritance.

The goal of all my tiny-* libraries is to create small, composable pieces for larger libraries or projects. I'd be very open to creating another library that provides this functionality.

Your thoughts?

[lazd]

It applies to composition as well as inheritance. When listening to events, the only real way to know if you've removed all your listeners is to keep track of them. With the current approach, the onus is on the implementor to do so (they must remember to explicitly remove the listeners). With the IoC flavors, an object knows how to blow away all listeners it has, or listeners it has to a specific object. This reduces the cognitive load of the programmer and, in turn, reduces bugs.

While I understand your desire to keep the library small, I'm concerned you really mean keeping the file size under 1k. I don't feel it's necessary to hold yourself to such arbitrary restrictions, and that including functionality is more desirable than saving a few bytes. I may be misinterpreting your messaging, though :)

If the intent is to create composable pieces for larger libraries, I would hope that I could get everything I needed related to events from one piece. Given that the mentioned functions make building larger libraries a breeze, I feel it's useful to include them in the piece itself.

You could certainly build another library, say tiny-emitter-ioc, that depends on tiny-emitter, but what is to be gained? Are the ~200 bytes that would be saved by omitting the IoC flavors worth the added complexity and the additional run-time cost of mixing in another object?

[scottcorgan]

You make very valid points. I'm weary of adding managed functionality, as I find flexibility (at least for this lib) a feature. BUT, I'm VERY open to exploring extending this lib in another lib with inversion of control.

Although, I'm not fully educated on implementing pubsub with ioc.

[lazd]

Cool, I'll close this issue then. Thanks for your consideration!