Re: [boost] Benefit/Complexity ratio in libraries [was MPLcontainers and algorithms]

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 
acceptance
 >of
 >> > MPL by Boost won't discourage others from submitting a more 
minimalist
 >> > 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
 >particular.
 >> 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?

--Beman