Merging Data and System

I was struck by the fact that I could invoke my Timer class either as a Event or as a Data. Aren't these things supposed to be different?

So I did an experiment where instead of having:
TimerData implements ComponentData
TimerSystem implements ComponentSystem

I swaped it into:
Timer implements ComponentData, implements ComponentSystem

And it works just fine!! You can access the Timer as either a event or as a piece of data. There are still big differences depending on how you access it, making it good to keep both types. But in this case there is no real advantage in keeping it two separate objects. After all, even if an outside component needs to access TimerData, it can still do so. The TimerSystem parts will be invisible, and vice versa in the opposite situation.

Let me show you two different ways we could structure the workings of our Timer component. These are the differences I've pinned down in my head.

DATA
entity.getData('timer',TimerComponent).useTimerCustomMethod(data);

EVENT
entity.dispatchEvent('TimerCustomMethod',data)

Despite this doing the same thing, there is a huge difference. First of all is that the top example with DATA is a singleton, It's saved under the hash string 'timer', if we saved another Timer under 'timer' it would overwrite the old one. The second example with EVENT is not a singleton, there could be several Timer classes that detects that 'TimerCustomMethod' event being dispatched.

DATA
var x = entity.getData('position',PositionComponent).x;

EVENT
<impossible>

Events cannot return information! It wouldn't even make sense, if you have several events hooked on, which one should be the one returning data? all of them? Events is always a one way street.


DATA
entity.getData('healthdata',HealthData).heal(50);

EVENT
entity.dispatch('heal',{amount:50});


The DATA example is strictly typed, while the EVENT example is more dynamic, with a silent failure. If you have a healing spell that can target ANY entity, you WANT it to silently fail if the entity doesn't have a health property. In addition, more than one thing can snap up the EVENT on the way and even modify it. If the entity has an ArmorOfHealing that doubles healing effects, then that would be very hard to implement on the DATA way, we'd have to hardcode a check, while EVENT it would be a breeze.



So, I hope you can see that even though these two things can be treated as one, they still differ so much in functionality that we need both. However, we don't actually need to treat them as two diffrent interfaces anymore, that's why I'm removing DataComponent and SystemComponent and replacing it with just Component. If you give it to an entity as Data, that works, and if you give it to an entity as an Event, that works.

Often you DON'T want the data and event to be merged. For example, the PositionData and the MovementSystem are very often related, but we don't actually want them to be one and the same. Because that that would mean that we'd be forcing an object which only has an position and can never move (say a button) to carry the deadweight of the movement code. We should still strive to be modular.

It's easy solved by simply making a component called Position and using it only as data, and a component called Movement and using it only as events. Just because we can merge related things doesn't mean we HAVE to do it.

It does makes sense in some places though, like the Timer class. TimerData and TimerSystem does not need to be two separate things, there is no situation where you want one but not the other.

Btw, I've made a "component" folder now and started filling it, to give me more structure. Things are going along nicely.