I’ve been involved with event-driven programming for years now, knowing it inside-out.
Here’s one of my comments on Robert Penners site, discussing the purpose of Flash event listener priorities:
As you can see – I’m very interested in the subject.
Quite recently, I stumbled upon a post on Unity3D Developers Group.
The post had a pretty bombastic title:
A Simple, Reliable and Blazing-Fast Event-System for Unity!
It was about a new event system for Unity created by some guy, called Epix Events (link).
Curious as I am – I decided to visit the page and see what’s it all about.
- the system seems to be inspired by the ActionScript 3 events
- it has a weak dictionary implementation (“WeakDictionary implementation from EpixCode to reduce the chance of creating memory leaks down to zero”)
- uses Native Extensions from C# (“once the code is in your project, absolutely any object can now listen or dispatch events”)
Now, the third point ringed a bell immediately (because of being a really bad programming practice), but more on it later.
There’s no past – we’re first and the best
What surprised me was really a tone of the post.
It sounded like a revolutionary thing never before seen with Unity, when in reality there are many existing event-systems available (one of them is eDriven).
Additionally, I thought the author has at least seen those systems, not to say he was probably inspired by them.
Just to be clear: there’s nothing wrong to be inspired (I’ve also been inspired by many things when making eDriven), and nothing wrong with re-using the open-source code (as long as respecting the terms).
However, I hate seeing individuals or companies simply trying to cover up the fact that systems they’ve been inspired with already existed when their system took place.
The “Silverlight” problem
I believe that it’s at least fair to mention from where the inspiration came from, as I did with Signals and Slots in eDriven framework:
Back to article. I asked the guy (Keven) if he checked out eDriven:
So, Keven clearly knew about my system.
However, his opinion on my system was something worth a debate. 🙂
In Part 2 of this post, I’ll try to defend eDriven and my design decisions.