Re: Formal Review: Signals

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-20 12:55:05

--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> On Tuesday 19 February 2002 06:19 pm, you wrote:
> That last parameter is a bit vexing, and deserves more 
documentation than it 
> has. It's a hack to get around the lack of partial ordering of 
function 
> templates. Consider:

[snip]

> I'll add this to the documentation.

Thanks.  Now I understand it better.  I'm glad you'll be adding 
documentation on this one.

> > * The use of other Boost libraries in the test programs is at 
least a
> > little suspect.  Failures in these other libraries may cause a 
mis-
> > representation of the suitability of Boost.Signals for a given
> > platform/compiler.  Note that I did not evaluate whether or not it
> > was possible/useful to factor these other Boost libraries out of 
the
> > tests, however.
> 
> There are three tests that fall into this category: 
dead_slot_test.cpp,  
> deletion_test.cpp, and random_signal_system.cpp. The former two use 
> Boost.Bind (this dependency could be removed without too much 
hassle). The 
> random_signal_system test relies on the BGL to mimic the signal 
connection 
> graph, and it would be horrible to rewrite all of that graph-
handling code. 
> Unfortunately, there are platforms (e.g., Borland C++) where the 
BGL does not 
> work but Signals does. Maybe I can just document around the problem?

Documentation isn't enough, but the solution isn't simple.  What 
would be ideal is some programmatic means to determine if the 
external library is supported by the platform and to skip the test 
with no success or failure response in that case.

This issue certainly won't exempt the library from inclusion, IMO, 
but we need some sort of solution to this problem for all of Boost.

> > * I wonder if some of the names used in Boost.Signals are too 
common
> > for placing directly in namespace boost.
> 
> I assume you're referring to 'connection' and 'trackable'?
> If so, I think the long-term goal should be to split the Signals 
library into 
> two: a Tracking library and a Signals library. Everything related 
to tracking 
> connections would become a part of the Tracking library, which the 
Signals 
> library would use instead of having its own mechanism. Then it 
might not be 
> so unreasonable for 'connection' and 'trackable' to be in the Boost 
namespace.

That only works if the "connection" and "trackable" concepts fit in 
the cases where the names would conflict.  For instance, a sockets 
library might have a connection class, and it certainly won't be 
compatible.  This is one of those sticky wicket situations where no 
matter which choice you make it will likely be the wrong one.  I 
commented only to insure some thought was put into it.

> > * It might be useful to have an overloaded connect() that takes a
> > second parameter of type trackable.  This would allow an 
alternative
> > to derivation from trackable, though at the expense of a more
> > complicated interface.  The trade off might be worth it to some,
> > though.
> 
> I think I'd like to think about other alternatives to derivation 
before 
> adding these overloads. I guess I'd prefer something like:
> 
>   sig.connect(track(some_function_object, a_trackable_object));
> 
> Then the notion of attaching additional trackable objects would be 
separate 
> from the notion of connection. This goes back to the idea of having 
a 
> Tracking library.

I like this idea even if it's not in a Tracking library :).

Bill Kempf