On Sun, Feb 29, 2004 at 11:51:28PM -0700, Jonathan Turkanis wrote:
Here is my formal review of FC++ -- sorry to wait to the last minute.
Wow, thanks for these extensive comments. I appreciate the time you spent and the many concrete pieces of advice for improvement. A few quick comments: I like your suggestions about how to generalize the "arity" aspects of functoids. A few people have already mentioned using the preprocessor or mpl or integer-valued template parameters, but your comments have been more specific and helped give me a better "global" view of how it should all work, ideally.
B) Rather than having users define direct functoids, then wrapping them in full functoids when they want to take advantage of 'sugar', it should be made easy to define full funtoids, so that all function objects designed for use with FC++ can be expected to be full. (One still needs adapters for foreign function objects, of course.) I think this could be done with macros, e.g.:
struct plus { // declare signature. BOOST_FCPP_LAMBDA_SUPPORT(2, plus) int operator() (int, int); };
I thought I remembered several reviewers suggesting this, but looking back, I don't see it. Brian's suggestion for allowing non-const reference parameters seems to require different overloads of operator() depending on which parameter types were declared to take non-const references. If this is true, more information might have to be passed to the macro to avoid an explosion of (mostly disabled) overloads.
One could still keep 'full' as an implementation detail, of course.
What's the motivation for this change? I am all for reducing boilerplate code, but I am unclear is that is the only reason you're suggesting this, or if there's another reason you want to avoid the "wrapping" mechanism in the current implementation. (I like the idea of "full-ness" being "just another combinator" (make_fullN).)
C) The technique for handling signatures of momomorphic and polymorphic funtoids can be unified. [...long discussion elided...]
A while back, I actually experimented down a road very similar to the one you describe here. I ultimately rejected this kind of signature representation, for a number of reasons (I don't recall them all right now--we can discuss it more off-list if you like). It has become so rare that monomorphic signatures are ever used/useful in FC++, that a viable solution to reduce the complexity here is simply to eliminate monomorphic signatures entirely.
Now, instead of writing reuser2<VAR, INV, VAR, T, U, V>, you write reuser2<T, inv<U>, V>. This looks easier to use, understand, and generalize. You might even be able to drop the '2'.
This is a terrific idea (wish I'd thought of it myself :) ). -- -Brian McNamara (lorgon@cc.gatech.edu)