Re: [boost] Re: Signals library updated

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-11-28 18:44:43

On Wednesday 28 November 2001 06:04 pm, you wrote:
> * 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).

Okay, thanks.

> * 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.

I'll document it, but I'm always open to suggestions regarding how to prove 
it. The desire to have an alternative mechanism to inheritance is a 
reasonable one, and was mentioned to me quite a while ago... I still haven't 
found clean solution :(.

> * 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?

The intention is that signal0<...> models AdaptableGenerator, signal1<...> 
models AdaptableUnaryFunction, and signal2<...> models 
AdaptableBinaryFunction. The standard library really doesn't have a notion of 
any function objects of arity greater than 2, and if someone is going to 
change that I think we really, really, really shouldn't continue with 
third_argument_type, fourth_argument_type, etc. but use a typelist instead. 

> * 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.

The basic reason is that when a bindable object is bound, one is binding to a 
particular instance of that object. So a signal instance is connected 
(several) bindable instances; when you perform a copy operation, you are 
copying the value of an object, not its identity. I can see I'll be writing 
documentation tonight :)

        Doug