[boost] Re: Re: full functoids

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
> standard.
>
> (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
per name).

> > Infix syntax: I am not sure I like the idea in a first place. But it
could
> > be discussed and added
>
> It is more useful when you have "named" operators as in FC++, simply
> because
>
>    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.

Gennadiy.