Re: Re: Conversion policies

At 23:40 2003-08-07, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > At 14:51 2003-08-05, David Abrahams wrote:
> >>Daniel Wallin <[email protected]> writes:
> >>
> >> > I've checked in a basic framework for conversion policies, like the
> >> > one we have in luabind.
> >> >
> >> >    boost/langbinding/policy.hpp
> >>
> >>Q1: Why use a handbuilt cons-list in lieu of mpl::list?
> >
> > Because I want to overload operator+ to compose the list. Also I want to
> > be able to have data in the policies.
>
>Oh, sounds like a tuple.

Yeah, it is.

> >>Q2: Conversion policies may carry data in them; it seems to me that
> >>     you need a runtime identification mechanism.  How about CRTP?
> >
> > Elaborate, where does CRTP apply here?
>
>Never mind; I misinterpreted your code.  I think it's finally dawning
>on me what it's intended to do... but a realistic usage example would
>be a huge help.

OK. Sorry for being vague. I'll try with some short examples:

This is the policy system which handles the converter generators and
precall/postcall. Consider a typical invoke-function:

template<class R, class A0, class A1, class Policies>
ret_type invoke(R(*fn)(A0, A1), const Policies& policies)
{
    // find the converter generators for the given parameter index
    typedef typename find_conversion_policy<1, Policies>::type conversion_gen1;
    typedef typename find_conversion_policy<2, Policies>::type conversion_gen2;

    // generate a converter for the associated type
    typename conversion_gen1::template generate_converter<A0, 
xxx_to_cpp>::type c1;
    typename conversion_gen2::template generate_converter<A1, 
xxx_to_cpp>::type c2;

    // the converter objects are later applied to the parameter passed from the
    // interpreter state to get the actual parameters.
}

The purpose of the xxx_to_cpp/cpp_to_xxx types is to have converter generators
that can generate converters for both directions.

template<int N>
struct my_converter_policy
    : converter_generator_tag<N>
{
    template<class T, class Direction>
    struct generate_converter { ... };
};

template<int N>
my_converter_policy<N> my_converter(boost::arg<N>)
{
   return my_converter_policy<N>();
}

...
def("f", &f, my_converter(_1)); // will generate lua_to_cpp
def("f", &f, my_converter(result)); // will generate cpp_to_lua
int a = object_cast<int>(get_globals(L)["foo"], my_converter(result)); // 
will generate lua_to_cpp
...

> >>     What is the purpose of the "N" argument in find_conversion_policy
> >>     anyway?  I guess some comments would be illustrative.
> >
> > It's the parameter index. The idea is that the caller does something like:
> >
> > typedef typename find_conversion_policy<1, Policies>::type policy1;
> > typename polic1::template generate_converter<T1, xxx_to_cpp>::type c1;
>
>Too many "parameters" running around.  I only just now figured out
>that you meant the index of a _parameter of the wrapped function_
>you're talking about (right?).

Right.

>Anyway, I'm not sure whether I agree with your implementation, though
>I agree with the spirit of it.  I'll have a much better idea when you
>show some more concrete examples.
>
>BTW, why do you have xxx_to_cpp and cpp_to_xxx tags?  Surely
>conversion for each parameter is only going in one direction?

Yes, but see above. The direction depends on the context. The converter 
generator
might just as well be used to generate converters in the other direction.

---
Daniel Wallin



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01