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).
> * 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 :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk