From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-02-20 04:35:55
> Given those definitions, function objects can be generally classified
> along 3 different axes:
> - they can be monomorphic or they can be polymoprhic
> - they can be adaptable or not
> - they can be rebindable or not
> "Direct functoid" is just the term we use in FC++ to describe
> adaptable, non-rebindable function objects. "Indirect functoid" is the
> term for "adaptable, rebindable, monomorphic" function object.
> boost::function objects are classified just like indirect functoids
> (adaptable, rebindable, monomorphic).
> My goal for the various "functoid" terms is not to introduce new
> vocabulary, but rather merely to simplify the exposition. Hopefully
> "standard" terms for these concepts will arise soon (I don't think they
> have yet). In any case, a "standard" implementation for result-type
> deduction has already arisen (result_of), and FC++ supports this
> (Let me know if I still have not answered/addressed your question.)
I do not think we understand each other. Let me rephrase. My position is
that polymorphic function object support does not belong to the library
dedicated to "functional programming", even though I propose to update
boost/functional.hpp header ;)) (BTW it would really help for the whole
library review, if you could provide a little introduction what is a
"functional programming" in a first place; how it differ from other
programming styles and what is the place of your library in this - I mean
what purpose does it serve, what solution does it provide). Also after
previous letter I found that you actually provide a lot more "functoids"
within the library, then counterparts to the STL functional.hpp function
objects. These should go in FC++ specific headers (and I mean headers - one
> > Infix syntax: I am not sure I like the idea in a first place. But it
> > be discussed and added
> It is more useful when you have "named" operators as in FC++, simply
> x ^plus^ y
> is often more readable/natural than
> plus( x, y )
> It may also be attractive to OO people, who have gotten into the
> now-fashionable habit of avoiding member functions. Switching from
> the member notation
> Shape s; Point p;
> if( s.contains(p) ) ...
> to the non-member notation
> if( contains(s,p) ) ...
> loses the subject-verb-object order; using function objects that support
> infix, however, lets you say
> if( s ^contains^ p ) ...
> which some people may find attractive.
And some really confusing. Moreover in a user code, above most probably
would look like if( s ^ boost::fcpp::contains ^ p ). It may be convenient it
you are using a lot of code like this. But since I not see problem domain,
I couldn't say how applicable it is to real practice. Also it only look
pretty for binary functoids. In any case I believe that if you do find it
widely useful and could "prove" that, this should be the feature also
implemented by boost::function.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk