[review] General comment on boost::singleton
Hi, I haven't looked into it at detail, but I've followed the discussion on the singleton's to be or no to be. 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....) Cheers, /Marcus
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcus Lindblom Sent: 18 January 2008 12:47 To: boost@lists.boost.org 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 accept that there are at least two concepts which are presented together, but I can see why - using singletons means you probably also want value initialisation. So I conclude Marcus's suggestion has merit. I sense it would be a Bad Idea to throw the whole proposal out. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
"Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:001a01c859db$d993ef80$0200a8c0@hetp7...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcus Lindblom Sent: 18 January 2008 12:47 To: boost@lists.boost.org 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
Marcus, thanks for your comment. I'll take this one as a motivation to express my general views on the issue: After eagerly defending the design, I begin realizing that not all the critique is naysayerism ;-). While I still think that the design is quite innovative and partially sound, it has severe inconsistencies: 1. 'mutexed_singleton's need for a generic context (IOW, no type to code against, except for 'lease' having unsuitable semantics), 2. inconsistent semantics of 'lease' classes of 'mutexed_singleton' and 'singleton' (with manually implemented synchronization). ... (several other issues raised during the review) I think that separation of concerns might solve the problems, however, it seems to me that I won't have enough spare time in one piece for it anywhere soon as it essentially means a complete redesign. Therefore, it won't cause me any sorrow if this library gets rejected. In fact, I'd prefer a rejection over acceptance with half-baked design. I think it has been inspiring nevertheless and I'd like to thank all who participated. In particular John Torjo for managing the reviews of my recent submissions. Regards, Tobias
participants (4)
-
Gennadiy Rozental -
Marcus Lindblom -
Paul A Bristow -
Tobias Schwinger