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

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

Giovanni Piero Deretta wrote:
> On Jan 16, 2008 9:07 AM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
>> Giovanni Piero Deretta wrote:
>>> On Jan 15, 2008 12:21 PM, Anthony Williams <anthony_w.geo_at_[hidden]> wrote:
>>>> John Torjo <john.groups <at> torjo.com> writes:
>>>>
>>>>> Today starts the formal Fast-Track review of the Boost.Utility/Singleton
>>>>> library. This is a very useful utility, so I'm expecting lots of reviews ;)
>>>>> * What is your evaluation of the potential usefulness of the library?
>>>> I don't think this is at all useful. People should not be encouraged to use
>>>> singletons, as there is already a tendency towards overuse. In most
>>>> circumstances, singletons are a poor design choice, so there is little
>>>> requirement for their use.
>>> I consider singletons just another form of globals and thus bad style.
>> Let's see:
>>
>>      "I consider if, else, for, do, while and the ternary operator just
>>       another form of goto and therefore bad style."
>>
>>
>> ;-)
> 
> Except that 'if', 'else' and friends are a *restricted* form of goto
> (i.e. the 'structured' in structured programming) and are thus
> acceptable. 

Let's see:

      "Singletons are 'structured' globals (i.e. the 'structure' in 'data
       structure') and are thus acceptable."

;-)

Some more fun:

      "I/O registers are global and thus bad style, so I built a computer
       without. Still trying to telepathically use that thing, though."

;-)

> In general, a singleton hardly adds any restriction to
> global (except from being thread safe). :)

Thread-safety is just a bonbon here: So let's take another look at the 
key responsibilities of a Singleton is for:

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.

Note that the need for 2.1. makes 1. even more important as you're 
limited to trivially constructible types writing a shared library that 
is supposed to work portably.

OK, that's about it. I might have forgotten something, but I'm in a bit
of a hurry, right now. Sorry.

Regards,
Tobias