It’s not really clear what the way I wrote it, but what I was referring to regarding Singletons was the declaration of the template type. Notice the two styles I used in the example:

// one – templated subclass declaration
class GreetHost : Host!(GreetPolicy) { }

// two – declaration at instantiation
Host!(GreetPolicy) h = new Host!(GreetPolicy);

The first technique is similar to what I had been using to declare templated Singletons (i.e. class MySingletonClass : Singleton!(MySingletonClass) {}). There are a few different ways to declare Singletons. I might write a post on it. Scott Bilas gives an overview of a few different Singleton styles in a Game Programming Gems article he wrote, An Automatic Singleton Utility, which is also available online. It’s C++ code, but can be translated to D with little difficulty.

Also I’m still not sure when to prefer one global object over the singleton pattern, maybe you could write a bit about how you work with singletons in D and cover this? I’d find it very cool

This really boils down to a matter of personal taste. The Singleton pattern, as simple as it is, is likely the least understood and most abused pattern in the GoF book. Some people insist that “globals are the root of all evil” and use Singletons as a means to avoid them. Some people insist Singletons should only be used for objects of which there should only be one instance. Some people avoid them altogether. I honestly fall into the middle camp (only one instance of an object), since that’s the problem the pattern is intended to solve. But to be honest, for I quite frequently just declare a struct with all static methods rather than using Singletons. It’s the same effect.

This is one of those cases where there really is more than one way to skin the cat. But I believe the circumstances of a project should dictate which technique to use and not the programmer’s preference. For example, if I were writing a library for others to use I would try do reduce the number of global objects exposed to the user. Internally, it doesn’t matter. But exposing globals outside of the library really can be evil, as they pollute the user’s namespace and make the library more difficult to use. I would also be hesitant to use them in projects with large teams, since they increase the chance for error. But, I personally would never use a Singleton solely as a substitute for a global because that’s not what the pattern is intended for.

As a general rule, anytime I have a manager class (GraphicsManager, InputManager, or whatever) I use a Singleton pattern (or the bastardized version I mentioned above — structs with static methods). Beyond that, it’s a case-by-case basis.

Also I’m still not sure when to prefer one global object over the singleton pattern, maybe you could write a bit about how you work with singletons in D and cover this? I’d find it very cool

e.g
Generic Pool: Policy based design : http://www.codeproject.com/library/Generic_Pool_Design.asp

Queue Manager: Policy Based Design : http://www.codeproject.com/threads/Queue_Manager.asp

Memory Map Class : Policy Based Design: http://www.codeproject.com/file/Memory_Mapped_Class___PBD.asp