From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-19 15:41:18
At 04:01 PM 8/19/2002, Joel de Guzman wrote:
>> > There are cases where having two ways of doing something makes no
>> > sense. But we shouldn't reject it out-of-hand. I hope the
>> > MPL by Boost won't discourage others from submitting a more
>> > library.
>> How many alternative libraries have been submitted for a topic that is
>> already covered by a Boost library?
>> This is a roundabout way to say that it _will_ discourage others. I say
>> nothing about this being good or bad, and nothing about MPL in
>> It's just that "competition" within Boost is virtually nonexistant.
>Is there a clear policy regarding this?
There isn't any explicit policy.
>I've always thought that it wasn't possible to submit a competeting
>library to boost. Even if it is possible, I'd imagine it would be an
>uphill battle. Correct me if I'm wrong.
Depends on how you define competing. To me, if two libraries take a
generally similar design approach, provide a very similar feature set, are
about the same size and complete, and really just differ in minor details,
they are competing. Yes, that would be an uphill battle.
But let's say two libraries take very different approaches. One uses
compile-time mechanisms for parameterization. The other uses runtime
mechanisms. Each has significant application areas where it seems better
suited than the other. Boost's current smart pointers and Loki smart
pointers come to mind. I think there should be room for both at Boost.
Or maybe one is really minimalist. Say a tiny xml library, which only
handles the "element" portion of the xml grammar, and nothing else,
contrasted to another which handles every XML related technology known or
proposed. These fill such different niches, why not accept each for Boost?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk