[boost] Benefit/Complexity ratio in libraries [was MPL containers and algorithms]

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-19 14:27:13

At 01:45 AM 8/10/2002, Andrei Alexandrescu wrote:

 >... it should be noted that all you really
 >have to absorb to start using Loki's typelists is this:
 >
 >template <class H, class T>
 >struct Typelist
 >{
 >    typedef H Head;
 >    typedef T Tail;
 >};
 >
 >Then, you can naturally use C++'s template engine, which supposedly you
 >already know, to work for you. That's why I'm saying that the 
dot-typelists
 >are closest to the way C++'s metaprogramming facilities work. 
Dot-typelists
 >have a complexity/benefits ratio that's, in my opinion, unbeatable.

I've often envisioned that concept as the benefit/complexity ratio of a 
library.

One problem is that benefit's can mostly only be measured in terms of 
applications, while a library's complexity is usually much more fixed.

I've heard Andy Koenig describe two libraries as one having 90% of the 
functionality of the other, but requiring only 30% of the code to deliver 
that functionality.

That's a round-about way of saying that where there is a much simpler 
library design (with relatively less benefits), and a much more complex 
design (with relatively more benefits), Boost should consider supporting 
both designs.

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.

--Beman