Re: [boost] [review] Fast track review of Boost.Utility/Singleton begins today

From: dherring_at_[hidden]
Date: 2008-01-18 09:30:31

My vote:  Accept the current implementation.

I initially thought boost should reject this singleton implementation 
because it bundles too many concepts into one package.  Others have 
pointed out some clear factorization points.

They looked something like:
template <class T> class singleton;
template <class T> class mutexed_ptr;
template <class T> class mutexed_singleton :
         public singleton<mutexed_ptr<T> >;

But a bird in hand is worth two in the bush...  While good ideas have been 
put forth, I don't see their implementation coming soon; and most of these 
changes should have little effect on the API.

Ramblings:
Despite the naysayers, boost needs a singleton framework (or at least some 
concise documentation on how to implement them portably).  Ignoring a 
common idiom won't make it go away.

A few purposes for singletons:
1) only create a single object
   As Anthony points out, this is generally bad and shortsighted.
2) establish a central point of communication
   This can be a good thing.
3) work around foreign APIs
   Singletons can save the day when working with callbacks in foreign APIs. 
Until everyone starts using functor objects or the like, singletons may be 
the only way to pass "extra parameters" through another library's callback 
API.
4) simplify public APIs
   Mirroring the previous point, "dependency injection" can horribly 
clutter an API.  Its fine for a couple things; but carried too far, it can 
introduce tigher coupling between and an application and a library since 
the application now has an active role in passing the library state 
around.  This is especially important when adding a new library to "legacy 
code" where social factors may prevent dependency injection while 
singletons allow more isolated changes.

Of these use cases, only 1 and 2 require special static initialization (3 
and 4 may use an explicit init() call).  Similarly, none of them require 
locking semantics, though locking should be easy to specify/enable.

- Daniel