RE: [boost] Review Request: functional

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-06-02 16:23:27

> That's a fair question.  The advantage of my functional.hpp is that it is
> an immediate fix to something that is quite broken.  People are already
> learning about how to use the standard adapters, but finding they
> invariably run into the references to references problem.  I want them to
> be able to retain their code and knowledge, but with a simple s/std/boost/
> fix their problems.
> 
And a fair answer.

> However, I certainly agree that in the longer term my code will become
> obsolete, as indeed will the compose.hpp that is already accepted.  But
> how far away are we from a complete, unified ET submission being accepted
> into Boost, 
> 
Well as usual, We didn't want to be first to try out the new review cycle.
Especially since lambda is a much larger block of code, and has features
still in development. So at least several months.

> and gaining widespread acceptance in books, etc so that
> people are no longer being taught to use bind1st/bind2nd?
> 
The paper is in the works, the book deal...well probably a long way off.
Acceptance into the standard even longer. Compilers being able to compile
the lambda implementation even longer. And therefore class lecturers using
it even farther out.

> Until that happens I think there is a place for functional.hpp. 
So do I. Boost is the place it belongs.

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.)

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.

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?

-Gary-

gary.powell_at_[hidden]