Maybe I shouldn't reply to a thread that has been dead for two years, but here goes...
Quote:Original post by Illco
Why must a singleton be in the global namespace whereas other objects do not have to be? A singleton is as globally available as any other type.
The problem with singletons is not that they're global as such - it is that they have global state. This means that there will be a multitude of places in your code that access, and maybe even modify global variables. This is a maintenance nightmare, especially in the later case. If your singleton doesn't have (mutable) state, you're safe (because, well, it's not a singleton then).
Monostates are exactly as bad, since they provide the kind same access to global mutable state. Actually they are worse, since it's not obvious that they share state.
Classes on the other hand, do not have state. Only instances do, and those are not global (they have to be explicitly passed around as arguments). Note that if you look at everything in your class that is declared "static" in isolation, you are looking at a singleton. If it has mutable state, you're probably in trouble.
My own rule is: don't make static variables, and don't make static constants that reference mutable objects. Note that this also excludes singletons. There really aren't that many exceptions.