Re: Signals library updated

From: williamkempf_at_[hidden]
Date: 2001-11-29 09:50:57

--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> On Wednesday 28 November 2001 06:04 pm, you wrote:
> > * 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 :(.

I'm not sure there is.  Just simple brain storming doesn't reveal an 
easy solution for me.  I definately agree that it would be very nice 
to find such a solution (maybe aggregation would work instead of 
inheritance?).  But this shouldn't hold up the submission or the 
acceptance of Boost.Signals.  I'd just like to see some rationale on 
why inheritance was used, even if that rationale is nothing more than 
admitting we can't think of a better 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. 

OK, I understand why you're striving for compatibility with those 
standard concepts.  However, there's a need for typedefs for the rest 
of the types.  If typelists will be used and we're just waiting for a 
Boost typelist (which is obviously coming) then I'd like to see some 
documentation stating this.  Otherwise (or until then) in addition to 
the standard typedefs I'd include argN_type typedefs.

> > * 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 :)

This is what I suspected, but obviously I think the rationale needs 
to be there :).

Bill Kempf