My Critique of Event Systems – Part 2

As mentioned in the previous post, I stumbled upon an event system for Unity, praised by its author:

Thoughts on Epix Events

Thoughts on Epix Events

Epix author also stumbled upon my library.

However, he believes his library is (somehow) superior ๐Ÿ™‚

Thoughts on eDriven

Thoughts on eDriven

My analysis of Epix Events

Since almost all of his arguments were wrong, I felt the need for answering:

Defending eDriven

Defending eDriven

And since I thought it might be interesting, I’m posting my (pretty long) answer here:

=============================================================

The only thing you got right is having hard references. eDriven is a framework for programmers, not a toy. We do clean up after ourselves (disposing listeners we do not need anymore). ๐Ÿ˜‰

Commenting inline:

> Of course! Itโ€™s a great library, but there is few reasons why I would not use it in my projects:

> -Itโ€™s asynchronous. Not a big deal in general but when you use events to manage animations or sounds, you donโ€™t have the luxe to wait few frames.

That’s weird, because all the listeners fire the moment you dispatch an event (it’s just triggering of the referenced methods/delegates).

There’s also an option for queuing multiple events and firing them in sequence later (very useful in Unity for doing stuff on next Update(), or similar). However, the immediate dispatching is the default.

> – From an architecture point of view, I think that offering events AND signal is a bad idea. Elegant architecture should not have two ways of doing the same thing.

If you build a GUI framework, you’ll need an event-type-of mechanism (because of event bubbling, data-binding etc.).

However, for any other type of communication – internal to the framework – signals are much faster because they are just passing values and not instantiating events (allocating memory). This is a performance optimization and not mandatory to use. You could do it all by using events. But signals are really fast, and adding virtually no code (just a few tiny classes).

But here’s a thought on the architecture POW: having a centralized event dispatcher (“notification center” or “messenger singleton” used by extension methods) isn’t as performant as having multiple dispatchers implemented at objects (so having listener references spread out to multiple dictionaries).

> – It’s all over the place. There is lot of codes when few lines is enough. Plus, for all the developers that donโ€™t come from a programming background, itโ€™s intimidating.

Didn’t get the first part, but I agree – developers should know programming ๐Ÿ˜‰

> – Too intrusive. You need to inherit from EventDispatcher in order to dispatch event.

Yes. That was the idea and that was the best I could do.

God objects are considered a bad programming practice (anti-pattern).
You are worried about having 2 parallel event systems, but not worrying about bloating ALL the classes e.g. giving superpowers to ALL the objects ๐Ÿ™‚

Using extension methods and manipulating .NET classes from within the framework is also considered a bad practice because of conflicts with other frameworks. What if I created the same extension methods within eDriven? (luckily I didn’t so Epix and eDriven could both be used within the same project)

Using extension methods is definitely not a new idea (it crossed my mind too), but framework developers shouldn’t misuse them by not taking care about things described above.

> You made me realize that EpixEvents is not pooling events tho, which eDriven do, I will add that ๐Ÿ™‚

Keven, if you are inspired by another MIT project, you should make a reference to it in your README.