Alright, merged. Yeah, some post initialize and pre join/cleanup callbacks could be handy. I suppose it gives you, at least, one level of initialize and cleanup order. To guarantee whatever it is you want to do in that function is called after initialization or before cleanup.
I would often recommend extending classes to provide more elaborate initialization and cleanup order. (most commonly that would be SceneManager or Scene). If you’re trying to create an order between two objects not in the same level of a member hierarchy, you might be doing something wrong, or just not encouraged. For instance, modules are, in part, designed to be independent from each other. But nothings stopping one from making complex sync mechansims, flags, waits, while loops, and state checking between them. Or just implementing their own driver/SimulationManager.
I do like the idea of better documenting events. Looking at a few APIs.
VTK is fairly similar to our event system now. They use types as well. They provide a list of events in the majority of their in code documentation (ex: https://vtk.org/doc/nightly/html/classvtkPointWidget.html#details). Additionally I have found you can just subscribe to all, then print the ids to see what it emits.
Unity provides no help on their events. But they do have examples. As far as I know.
I love how Qt does it. They provide a beautiful list of signals and slots with descriptions for each online. This is most easy for them because each signal and slot is a function definition. So they can just provide descriptions above the function. And when you go to type out a connection it goes like connect(sender, sender func, reciever, reciever func). So in intellisense you can float your mouse over that sender/signal func and see, that or look it up online. Also the function name tells a lot.
For us to do the same, such that there is a function definition that posts the event. And that same function is directly used when calling/filtering connect. We would need to store observer callbacks in the sender, by sender func instead of event type. I might expirement with this later. More extensible. Though I get the feeling I did when I first coded it.
What happens now is the sender stores each observer/subscriber callback by event type, so when an event of type X is posted, only the observers that are listening to that type, are called.