Irritating shortcoming with modules and externs

[Mike Parker]

Bruno Medeiros wrote:

> 
> However, in my case, App is a module. If you only have one Context, and 
> it is allways active during the program lifetime, why bother creating a 
> singleton instead of simply using a module?
> 

It's not really a singleton that I am using. It's an abstract class that 
sets a specific variable once when the first instance is constructed. 
You can create as many instances as you want after that. In my case, it 
is used in conjunction with a stack-based task (or state) system

In a game, you have different game state transitions. The title screen, 
multiple menu screens, the game play screen, and so on. Encapsulating 
all of these into state instances and using a stack to manage them makes 
it easy to transition from one state to another and back.

The example I gave is not how I'm actually using it, but close enough. 
The first state instance that is instantiated is added to the state 
manager as the default state and is never removed from the stack. This 
is done in the constructor of the abstract base class, allowing the game 
engine to maintain control flow and do a lot of core setup (reading 
config files, initializing the display and audio systems, and so on) 
behind the scenes.

The primary state instance is created in a static module constructor. I 
pass that module to Build, which can then compile the entire game engine 
along with it if I don't precompile it in a library first. I can 
implement multiple games by implementing different modules with static 
constructors that instantiate a default state and pass those to Build 
instead. And, if I wanted, I could implement the entire game using one 
state and never bother implementing others to transition to. It's a 
pluggable system that abstracts away quite a bit.