Re: Signals library updated

From: williamkempf_at_[hidden]
Date: 2001-11-28 18:04:53

--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> The Signals library has been updated; the new version is at:
> http://groups.yahoo.com/group/boost/files/Callback/signals-
20011125.tgz
> 
> Changes in this version include:
>   - Fixes for MSVC and Borland C++
>   - Added Documentation: design rationale & comparisons with other 
signals & 
> slots implementations.
>   - signal connection now meets the strong exception guarantee 
>   - Jamfile fixes for building the "bindable.cpp" test
>   - combined transform_iterator, skip_if_iterator, and 
input_caching_iterator 
> into a single slot_call_iterator to reduce template depth and 
compiler 
> confusion.

A couple of comments:

* Under the Rationale, delegates are not C# specific.  They are 
a .NET concept available to all .NET aware languages (this includes 
MC++, managed C++).  I'd change the header to read ".NET delegates" 
instead (with appropriate changes to the text as well).

* I generally dislike forcing inheritance on users when you don't 
have to.  It can cause too many problems with the classic diamond 
shape heirarchy, and working around this can often be a huge pain.  
When possible I now prefer to use generic code to achieve the same 
thing with (slightly) less impact.  I'm not necessarily suggesting 
this be done here as I've not studied any of the implications in this 
design, I'm just suggesting that rationale for the choice to use 
inheritance may be appropriate to document.

* signalN.html only mentions first_argument_type and 
second_argument_type.  If there's three arguments is the third type 
third_argument_type?  How do you manage to define these names through 
macro magic?  Or is this a documentation error?

* Even though I *think* I understand the rationale, I think you need 
to add documentation for why bindable copy semantics (both copy 
constructor and assignment operator) result in non-exact copies, i.e. 
they disconnect all current connections and don't copy the connection 
state of the RHS.

I haven't been able to look at the implementation in depth, which 
isn't going to be easy any way because of the macro magic used (not 
that I think the macro magic should be removed!).  However, I do like 
what I've read in the documentation and I'm very glad to see this 
concept submitted for inclusion in Boost.  For me this rounds out the 
concepts needed for "function object" usage, though some Lambda style 
creation semantics can still simplify some things for users.

Bill Kempf