Boost logo

Boost :

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
> > 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
> > third_argument_type? How do you manage to define these names
> > macro magic? Or is this a documentation error?
> The intention is that signal0<...> models AdaptableGenerator,
> 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
> third_argument_type, fourth_argument_type, etc. but use a typelist

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
> > to add documentation for why bindable copy semantics (both copy
> > constructor and assignment operator) result in non-exact copies,
> > they disconnect all current connections and don't copy the
> > 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
> (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
> documentation tonight :)

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

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at