For my next task I've decided to skip ahead a bit and design the kernel, otherwise known as the game loop. With the signal code in place this isn't that difficult to code; it really is just a loop that keeps sending signals until it gets told to quit. The main decision that needs to be made is how these modules will interface with each other using signals.
After sketching things out on paper, I can't help thinking that the best method for doing this is to define the signal interfaces outside of the class they "belong" to as signal objects out in global space. My initial thoughts on that proposal is my inbuilt reaction that globals are evil nasty things that should be avoided at all costs unless they are unavoidable. But all other solutions I can think of are either as convoluted as all hell or are globals in disguise (like singletons). The point is that with this architecture the signals are the main interface with core modules like the kernel and many different modules may need to connect up to it, and I might as well make the interface the signal itself rather than wrapping it up with pretty functions just to pretend it isn't global. Of course, all the signals will be contained within namespaces so it's not as if they'll be trampling all over the code base.
Now I just have to decide on a naming strategy for signals. I'm usually not a fan of code warts because I feel they make names harder for humans to parse, but in this case I might need something to signify that this is a signal. Maybe something like sig_KernelUpdate? Although I'm not sure about the "KernelUpdate" part...
