Use enums as event types
svenstaro opened this issue · comments
We originally used strings in event types because this ensures that client even ids wouldn't collide with others. Using enums will likely cause no realistic problems. The enums should have explicit types and values though.
I think I could do this. By explicit types and values do you mean
enum EventTypes {
Type1 = 0,
Type2 = 1,
etc...
}
Yes that is right. You know that this affects all events, the string manager, the network manager and all event listeners!? If you know how much of a change that is, you can do it. Every event type will be replaced by a uint32_t. When the type of an event from within the engine (engine/src/.../...Event) is needed, take that from the enum. When you need an event outside the engine (e.g. in the tests/samples) you need to define another enum.
Please start with ID 65536 for enums outside the engine, everything below is reserved for the engine.
Ah well, explicit type (you missed this, it is c++0x stuff):
enum EventTypes : uint32_t { ... }
explicit value:
Type1 = 0, Type2 = 1, ...
we need both.
hmm, I knew the string manager and events were affected. Is this going to have to be dynamic, as in, you could make a new event during scripting or is it just going to have a list in Event.hpp? Doesn't the network manager just use the clone method? I'd also have to figure out how the id's work. You're right, I may have underestimated this.
Well we will just assign each event class a unique ID. Or well, the engine's IDs will be unique (somewhere in the rage 0 .. 65535) and the actual IDs are saved in an enum like the one you proposed.
All other events will need to hardcode an ID above 65535, we must then hope that there will be no collisions. But the range 65536 .. 4 294 967 295 should be big enough :D
So change Event::GetType() to return uint32_t, and change all occurrences of that (i.e. in all events) to fit. Notice that all events created outside the dt namespace will need IDs > 65535. Put all the IDs inside the namespace into an enum (so we don't have to hard-code them outside the enum definition and don't confuse them).
So actually, the IDs will not be dynamic, but it is also no good idea to define an event inside a script, better use a generic one (it is difficult enough to export a class to the script (with constructor and stuff), backwards is probably even worse). So for scripts we will have events like "MessageEvent" (you can send a string with it) or similar.
Wouldn't those ids just become the event's place in the enum, and we wouldn't have to mess with StringManager::GetId() anymore? And just so I'm clear, everything in the engine folder is the engine, right? So I wouldn't have to mess around with id's > 65535 except maybe in scripting?
Yeah. IDs replace the string types, so the string manager GetId() becomes obsolete - but leave it for now, we might use it later (it just maps strings <-> IDs, so we can use it everywhere, not just with events).
Yes, everything inside engine/ is the engine, everything in tests/ and samples/ is treated as if it were not part of the engine. So if you need to assign an ID outside the engine/ folder (for example in ChatMessageEvent::GetType()) you need to give it IDs >= 65536.
I don't think it's worth it, I've only found 10 engine events. Every other, custom event, whether it's in a test, or a script, would have to use the strings.
nonono no strings. You got it wrong. EVERYONE uses IDs (uint32_t). Inside the engine as well as outside. Only whenever you would write the integer (e.g. 10 or 42) as a const expression inside the engine, just write
(uint32_t)EnumTypes::WANTED_ENUM_TYPE
so you don't have to remember the exact number. Never again use strings. They are evil.
Functionally works fine. 2 questions: should all event types be uppercase like system events? I had the custom ones written like "customEventType".
I figured the event registry would only need to be called during debug, but I don't whether the #ifdef stuff should be in the program files around "RegEventType" (more typing for user) or inside the RegEventType function(RegEventType would be called regardless of debug status, it just won't do anything).
Looks good so far. I answered your questions in the pull request. #149
Everything in your comments is fixed, but I closed the pull request, because apparently everything's getting switched to signals anyway. I can re-pull request, though.