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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-16 06:57:39

Whoops, I accidentally hit 'submit'... Here's the second part:

Anthony Williams wrote:
>>> thread_specific_singleton is overly complex for what should just amount to a
>>> simple use of thread_specific_ptr.
>> It uses 'thread_specific_ptr' and has additional responsibilities.
>>
>> Could you be more specific, please?
> 
> thread_specific_ptr on its own provides for one instance of an object per
> thread. I disagree that a class should impose that there is one and only one
> instance per thread (and no globals) --- this is a decision for the user of a
> class, not for the class itself. As I understand from the docs, the additional
> responsibility is the destruction order management. I agree this is a useful
> facility to provide, and think it is independent of the singleton nature of
> the classes, so should be separated into its own class.

The responsibilities of a Singleton. Citing another post (sorry for the
redundancy -- I think I'll add a brushed-up version of this list to the
documentation):

1. Making the user implement a class
1.1. encourages a well-defined object interface,
1.2. embraces a design that can easily be changed to use non-globally
      scoped objects instead, and
1.3. prevents pollution of the global namespace.

2. Providing on-demand initialization
2.1. makes non-trivial construction work with any ABI's shared libs, and
2.2. automatically resolves dependencies between Singletons.

3. Ensuring a single instance of the Singleton class
3.1. allows to properly model unique facilities (hardware, registries,
      etc.) in an object oriented fashion, and
3.2. allows to encapsulate a well-defined access point in the first
      place.

> 
>>> I've written code that used singletons (and regretted it later), and used
>>> code that other people have written containing singletons.
>> So you should like this library: The design chosen allows you to easily
>> substitute Singletons with Smart Pointers.
> 
> I disagree. If people know something is a singleton, then they don't bother
> keep the reference around, as they can get it again later. Changing code that
> does that to code that can use a passed in instance requires adding parameters
> and/or storing references. You can't just change uses of a singleton to use a
> smart pointer instead without thought to *how* it's being used.

I won't argue on this one. I can imagine that having to refactor a mess 
like this is a most unpleasant experience.

Still it's not the fault of the Singletons but of developer's laziness: 
At least the developers in the project you mention had a choice whether 
to write flexible code or not. With globals and static functions, they
wouldn't have had a choice but to make a mess.

Regards,
Tobias