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

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-01-16 09:10:00

Disclaimer: I'm just discussing the singleton patern per se.
I haven't read the documentation of Boost.Singleton nor I can comment
on its design.
I'm not voting for nor aganist the library.

On Jan 16, 2008 12:05 PM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
> > On Jan 16, 2008 9:07 AM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
> >> Giovanni Piero Deretta wrote:
> >>> [...]
> >>> 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."
>

Hum, the difference between "structured programming" and goto-based
programming is well known and I didn't feel the need to define it.
(but if you really want to:
http://en.wikipedia.org/wiki/Structured_programming)

What is not obvious (to me at least) is how singletons are more
structured (in the sense of 'data structure') than a global object.

>
> 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."
>

How *hardware* I/O registers have anything to do with software
engineering best practices?

>
> > 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.
> [...]

The problem is that most of these points just make globals more
usable, do not really address the problem with globals: an implicitly
shared resource.
In particular:

> 1.2. embraces a design that can easily be changed to use non-globally
>       scoped objects instead, and

How? Or you design upfront not to rely on a non global scoped object,
passing around a state pointer and not assuming global visibility of
changes or you don't.

> 3.1. allows to properly model unique facilities (hardware, registries,
>       etc.) in an object oriented fashion, and

I do not think you can usefully provide an OO interface to hardware
registers, and anyways what is unique in one release of your hardware
might not be in the next one.
There might be higher level abstractions that are best modelled as
singletons. The point is, are these common enough that they deserve a
generic solution?

--
gpd