From: Doug Gregor (dgregor_at_[hidden])
Date: 2008-03-27 14:04:58
On Mar 18, 2008, at 2:12 PM, Frank Mori Hess wrote:
> On Tuesday 18 March 2008 10:24 am, Jeff Garland wrote:
>> Why does it require a review -- isn't this just an extension of an
> I'm not sure exactly where the threshold is for needing a review, so
> I'll just
> list some reasons it might need one.
> * The scheme for managing connections is different, people should
> have an opportunity to disparage it before it gets forced on them.
> There are
> also some new classes for supporting postconstructors/predestructors
> may not be needed after all, if I can get my changes to
> shared_ptr/enable_shared_from_this accepted).
> * It's not fully backwards compatible. I dropped the old connection
> management scheme (boost::trackable and visit_each) entirely. It
> could be
> made to be (almost) fully backward compatiible for source code, if
> deemed necessary. However, it's also been pointed out that now may
> be a good
> time to do some namespace and header location rearrangement to bring
> more into line with current boost policies. Actually, I'm already
> aware that
> some of my new classes (postconstructible/deconstruct_ptr/etc.) that
> I dumped
> into the boost namespace should be moved. It might be worth
> continuing to provide the old boost.signals library for a transition
> moving thread_safe_signals into a new namespace/header location
These two are probably enough reason to hold (at least) a mini-review,
especially because the natural way to integrate thread-safe signatures
is to have it replace the Signals library entirely.
> In any case, I'm certainly not in a position to start ripping out
> boost.signals and replacing it with my code, until there has been
> some kind
> of review or blessing given to me to do so. Doug gave encouragment
> to embark
> on the project originally, but I don't think he's ever given any
> stamp of approval to the final implementation.
I think some kind of mini-review (say, 4-7 days) of the implementation
and its interface changes, followed by a staged introduction of the
new implementation over two Boost releases, would make the most sense
for this library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk