From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-02-19 02:58:12
This is a comment actually to all three "factoid" related parts of the
I am not very familiar with functional programming terminology and
paradigms. And I do not like inventing new word without substantial reason.
So here is my understanding on what this part of the library all about and
my thoughts on what shout be done. Please point if it is simply silly and
C++ standard introduces and STL uses notion of function object a generic
abstraction for function. By design it is structure type with non-template
operator(), where types of the arguments and result types are unambiguously
defined by the type of function object (it could be hardcoded types or types
dependent on structure template parameters). So let's call it monomorphic
function object, opposed to the alternative design for function object,
which uses member template operator() which we will call polymorphic
function object. Polymorphic function objects in some ways better/more
powerful than monomorphic ones. But there is an issue of result type
deduction, which require special support. Solution is described in mention
by you paper and your library implements it (as I understand it).
Now the question is why would we need separate notion of functoid, while
we already have powerful abstraction for function objects presented by
boost::function? Why boost function does not present this functionality (if
it does not, I am not sure)? This looks like obvious place to implement this
solution: you provide helper facilities to make it easier to write
polymorphic function objects and you make boost::function polymorphic
function object aware (even though it still be a model for monomorphic
function object). This will cover indirect functoids also. (BTW why do you
need virtual for it's implementation - I did not see single one in
Currying: I have a question: why boost::function does not provide currying
internally? Why do we need boost::bind? IMO polymorphic function object
currying should be incorporated in boost::bind.
The same applies to lambda facility.
Smartness: I believe boost::function interface may be extended a little if
we find your addition convenient. But as for now arity seems to be good
Infix syntax: I am not sure I like the idea in a first place. But it could
be discussed and added
Also it's my understanding that library provide corresponding polymorphic
counterparts to STL functors defined in <functional>. I believe we do need
to do so, in boost/functional.hpp.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk