RE: [boost] Review Request: functional

From: Beman Dawes (beman_at_[hidden])
Date: 2000-06-06 10:22:25

Gary Powell has raised several important questions about overlapping
libraries on boost.  In general, the issues are difficult and I don't
think we can completely settle them yet.

So let's try to make some progress on specific issues.

Functional
----------

Functional is in process of being scheduled for formal review.  Let's
assume that if functional is accepted into boost it will include
sufficient documentation so that potential users will understand why
it exists, and why it is a short term solution to a specific problem.

As Gary put it:

>For functional.hpp if/when its accepted I'd just like to see a note
on the
>web page explaining why it exists. Then as we add more
>functionality/code/libraries to the binding problem users can pick
and
>choose depending on their compiler, risk aversion, and knowledge.

So for now we just let the functional formal review run its course.

Lambda and Expression
--------------------- 

Gary's statement of the problem:

>Part of the reason I posted the question is the overlap of Lambda
and
>Expression. Lambda currently has a lot more features, but expression
uses
>less new features of the language and therefore can be used on more,
but not
>all compilers. The two libraries use different names for similar
functions.
>For these two overlapping libraries it would probably be a good idea
if the
>interface were "standardized" but not too soon. So that users could
switch
>from one to the other by recompiling. By not too soon, I mean I'd
like to
>see more usage of this code to see which idiom works better in the
field.
>(Or maybe none of it does, in which case we could re-work them
both.)

Assuming there really is a lot of overlap, I don't think boost should
supply both.  Furthermore, it seems unfair to the authors to ask that
they continue to develop and support both libraries when the final
intent is to reject one.

Here are the possibilities I see, ordered by my preference:

A) The authors work together off-line to have one library subsume the
other.

B) The authors agree to disagree, and produce a description of the
technical merits of each library.  This gets posted to the mailing
list, and the members decide via discussion, and a vote if necessary,
which library to support.

C) Boost provisionally accepts (via formal review) both libraries,
with the understanding that eventually one will die (at least on
boost).

D) Boost accepts (via formal review) both libraries on a permanent
basis, and lets users decide which they want to use, hopefully with
some guidance.

Whichever approach is taken, I don't think that broken compilers
should be the driving force in making decisions.  See below.

Broken Compilers
----------------

>The downside is that boost libraries which include other boost
libraries
>need to use the least common denominator of compiler compatibility.
i.e. if
>library A doesn't itself require features of the C++ language
library used
>by library B, it should use Library BLite instead.  What a headache!
Because
>we can't reuse our own code! And if not us, who will use it?

It is useful to accommodate broken compilers only if it doesn't
compromise the key design features of a library.  Broken compilers
eventually get fixed or get abandoned.  Don't make big-picture
decisions based on compiler idiosyncrasies.

Boost authors should use other boost libraries when they think the
benefits outweigh the costs.  Compiler issues can be one of the
costs, but shouldn't dominate.  Benefits versus costs related to
coupling are more important in the long run, for example.  Don't
fixate on compiler issues.

--Beman