Re: [boost] [Review][PQS] Concept names?

From: David Abrahams (dave_at_[hidden])
Date: 2006-06-08 12:34:38

"Paul A Bristow" <pbristow_at_[hidden]> writes:

> boost-bounces_at_[hidden]  wrote:

Paul, can you fix your mailer's misattribution problem?

Dave Abrahams wrote:
> |  Aside from nits and naming convention issues,
>
> I am sure that your expertise is invaluable and welcomed here.
>
> | I feel especially strongly that we must not muddle the ideas of generic programming.
>
> Could you elaborate on this?

I think I did fairly extensively in the post you're responding to.

> Are you saying that there is a problem with the documentation, or
> with the design?

Yes. :)

Documentation and design are not wholly distinguishable from one
another, especially not when it comes to generic programming.

> (Boosters seem to continue to accept vital tools like Test and Build
> whose documentation is in a MUCH less than satisfactory state, so I
> can't see that this should be grounds for rejecting a submission,
> only urging its improvement).

The sins of the past do not justify making the same mistake again.
IMO we have recently allowed too many libraries into Boost with
inadequate documentation and especially with a muddled expression of
generic programming, which is too poorly understood in the C++
community at large.  For years, Boost set the standard for generic
programming outside the STL, and that standard has recently become
diluted.

For the record, although I agree both should/must have better docs,
neither Boost.Test nor Boost.Build has much to do with generic
programming.

> |  I think this is an important domain and I hope we'll be able to
> |  accept a different version of this library, but, with regret, I
> |  vote against the inclusion of this one in its current state.
>
> We have been trying for years to get towards a useful solution to
> this exccedingly important area, which has application in 9 out of
> 10 real-life programs.

Well, maybe.

> The C++ language tantalizingly promises to make possible auto-type
> checking, converting and displaying the myriad units, but keeps
> tripping us up with vital missing features like typeof, or well fall
> at the compile speed hurdle.
>
> What design changes would persuade you to vote for this attempt?

I haven't looked at enough of it to know if there are other issues,
but in order to resolve my problems with the issues I've raised:

  Clarity and conformance to Boost/C++ standards and conventions.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com