Re: [boost] [review] General comment on boost::singleton

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-01-19 17:38:47

"Paul A Bristow" <pbristow_at_[hidden]> wrote in message 
news:001a01c859db$d993ef80$0200a8c0_at_hetp7...
> >-----Original Message-----
>>From: boost-bounces_at_[hidden]
>>[mailto:boost-bounces_at_[hidden]] On Behalf Of Marcus Lindblom
>>Sent: 18 January 2008 12:47
>>To: boost_at_[hidden]
>>Subject: [boost] [review] General comment on boost::singleton
>>I think the singleton lib is good as a boost addition, because having
>>many different singleton implementations suck. I also think that boost
>>should encourage good code style.
>>
>>Therefore, I vote for an implementation that both separates
>>the concepts
>>provided (i.e. safe construction, uniqueness, global access & locking).
>>The lib should also provide some kind of unifying scheme, so that the
>>"classic-singleton" can be achieved by applying everything.
>>
>>Also, I think some good motivational documentation on why the classic
>>singleton is not a scalable idea would be appropriate, so that we could
>>get users to think about the orthogonal concepts and whether
>>they really
>>do need all concepts in one go. (Many of us have found out that we only
>>need a subset, after much pain....)
>
> Like Marcus, I've also looked briefly at the docs and followed some of the 
> discussion.
>
> I sense that singletons do have uses, despite some intemperate 
> 'fundamentalist religious' objections.  And I think a Boost singleton
> must be a Good Idea, even if not to everyones taste - they don't have to 
> use it.

I, personally, have no fundamental objections to the singleton per se, but 
the sumbitted desing contains major flaws IMO and promoting it, by allowing 
it in, we would make a mistake. Following bad desing is as bad as 
reimplementing the same idea every time. In fact later is might be better, 
casue at least you have a chance to do it right.

Boost still have some respect in a community. Following the design ideas 
promoted by this submission, people will start implementing 
syncronized_vector, thread_specific_factory etc.  I'd prefer to avoid this.

Gennadiy