Date: 2001-04-03 08:45:36
--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: Beman Dawes <bdawes_at_a...>
> > The suggestions to add features (via generative programming or
> > make me very nervous.
First, thanks Beman for expressing what I tried to much more
succinctly and elegantly. Generitive approaches add complexity, both
for the user and for the implementor. In many cases the benefits far
outweigh this cost, but in this case I don't think that will turn out
to be true. *Any* added complexity for the user is a bad thing here.
> > Multi-threading is notoriously difficult to get right. The
experts as far
> > back as Dijkstra, Hoare, and Brinch Hansen have argued time and
> > for minimalist approaches to concurrent programming.
> > Keep examples like std::basic_string<> in mind. It tried to make
> > happy, even though needs and wants varied a great deal. The
> > general unhappiness.
> > Keep Boost.Threads simple. Don't try to solve every multi-
> > problem the first release. It just isn't the right library to
use as an
> > experiment in new techniques like generative programming. Or to
> > with features for everyone. Just my opinion, of course.
> I hate to argue against K.I.S.S., and I don't have an opinion
> on whether or not a mutex generator is the way to go, but it
> does seem that we have already decided against the Hoare/Hansen
> approach of a minimal language extension in favor of a set of
> lower-level primitives.
This is not precisely true. We can't provide a language extension,
only a library extension. Other than that, the decision to provide
lower-level primitives was made for two reasons: 1) there are
several higher-level concepts to choose from and there's no concensus
as to which of these is "the one true path to enlightenment" (CSP is
one promising path, for example) and 2) any of the higher level
concepts are going to require lower level primitives to implement
them. The goal is to provide the lower level primitives to be used
as the building blocks for several higher level concepts.
Hoare/Hansen do the same, only on a different scale since they're
providing language extensions for specific higher level concepts.
> I'll also point out that one can first develop a set of classes
> and later devise a generator for that set, so we may not need to
> choose right away.
I'd very much agree with this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk