Re: [boost] Re: Review Request: FC++

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-08 18:06:35

On Wed, Oct 08, 2003 at 02:39:47PM -0400, David Abrahams wrote:
> 2. I strongly urge that you review the conventions used for
> interoperability with the MPL's idioms.  For example, the definition
> of mymap from the examples might be:
> 
>   struct mymap_type
>   {
>       template <class F, class L>
>       struct apply
>       {
>          typedef list<
>              typename mpl::apply<F,typename L::value_type>::type
>          >
>          type;
>       };
> 
>       template <class F, class T>
>       typename mpl::apply< F, list<T> >::type
>       operator()( F some_func, list<T> some_list ) const { ... }
>    } mymap;
> 
> The use of a nested "::apply<>" instead of a nested "::sig<>" makes
> mymap_type into a *metafunction class*, and the use of a nested
> "::type" within "::apply" makes it into a *metafunction*.  

I have no objections to this.  I'll put it on my to-do list (should be
easy).

> I'm almost certain that you could take advantage of MPL with these
> conventions within FC++ for a substantial reduction in code and
> complexity, and a corresponding increase in portability. 

This is not apparent to me.  But then again I am not (yet) an MPL user.
But then again, I do have a lot of experience with the library
internals, which suggest to me otherwise.  But who knows.  I am all for
"reduced complexity" and "increased portability".  But I may need some
help "seeing the light" (if there is such a light to be seen).

(I do believe that there are portions of the implementation (in lambda)
which almost certainly could benefit from MPL.  It's not so clear to me
that MPL has any utility with the general "sig"s.  But we'll see.)

-- 
-Brian McNamara (lorgon_at_[hidden])