Oops! That SHOULD indeed be a function! ;-) Ta for spotting that!
Also, you're right regarding using a singleton with many modules, it's not something I've had to do, and it's a very valid point.
I also use Create. The above code (modified now to remove my bug!) is an example of the way we've built our Flow demo and it helps with fast development and also, if you decide to change the underlying engine, the interface doesn't have to change as long as you provide get/set methods. :-)
I DID have a rethink after Ratchet posted the code above and you are also right with Create/GetInstance(). They might as well all be the same code, it would make no difference. By the way ratchet, you should probably put your functions in the type!
In short, you've persuaded me that your way of using the Singleton is in fact valid and has more uses than my own code. :-)
Saying that, the Tplayer stuff in my code is also pretty handy for others ;-)
Also, you're right regarding using a singleton with many modules, it's not something I've had to do, and it's a very valid point.
I also use Create. The above code (modified now to remove my bug!) is an example of the way we've built our Flow demo and it helps with fast development and also, if you decide to change the underlying engine, the interface doesn't have to change as long as you provide get/set methods. :-)
I DID have a rethink after Ratchet posted the code above and you are also right with Create/GetInstance(). They might as well all be the same code, it would make no difference. By the way ratchet, you should probably put your functions in the type!
In short, you've persuaded me that your way of using the Singleton is in fact valid and has more uses than my own code. :-)
Saying that, the Tplayer stuff in my code is also pretty handy for others ;-)