Re: Re: Conversion policies

At 21:31 2003-08-26, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> >>I confess, though, that I am really confused about where this is
> >>coming from, since I was sure you had agreed that "100% compile-time
> >>converters" are not worth their costs.
> >
> > Yeah you're right, I did agree to that. I'm just trying to clear
> > things up. ;) It is still unclear to me how runtime and compile time
> > converters will interact though
>
>Didn't we just say there weren't going to be any "compile-time
>converters?"  Or did you mean something else?

I don't know, we certainly already have a system which allows for
both type of converters.

IIRC, during earlier conversations we did agree that runtime converters
was better, but that it should also be possible to override the runtime
system with compile time selections.

I don't know if this is still a viable approach, but I'm just trying to
keep the discussion open.

> > like in the case of our "adopt" policy.. In luabind it's a
> > converter, in langbinding perhaps it will be a policy with a
> > post-call action which removes ownership instead. I don't know..
>
>Err...
>
>I don't see how "it's a converter" vs. "it's a policy" is anything
>more than a name game.  Ultimately it needs to do the same thing.

We are yet to define "policy" and "converter" in langbinding, but in luabind
they are different things. Policies can generate converters, but they don't
perform any actual conversion. They do however have static pre/post-call
functions.

>As for whether ownership is removed post- call, it may be important to
>choose pre-call removal in case an exception is thrown from the call
>and the callee has already claimed ownership.

Ok, is this less dangerous than assuming the callee never got to claiming
ownership?

> >> >
> >> > The problem here is that the constructed temporary will be destroyed 
> before
> >> > it's returned from object_cast<T>(). Given that object_cast<T> is
> >> actually a
> >> > function rather than a type with implicit an cast to T of course..
> >>
> >>It's called "extract" in Boost.Python and
> >>
> >>      1. Yes, it's a type with an implicit conversion operator
> >>
> >>      2. Extraction of a reference to a temporary should fail at runtime
> >
> > Ok. Out of curiosity, why should it fail at runtime?
>
>Because we can't make it fail at compile time?  It's clearly an error!

Yeah, I misread the second point. What confused me was that in Boost.Python
this would work fine, no? If I'm not mistaken no converter returns an actual
temporary, but rather const& to in-place constructed objects..

Obviously it should fail if the converter does actually return a temporary..

> >> >> > One thing that would be cool is if you would be able to chain
> >> >> > compile time selected converters with runtime dispatch
> >> >> > converters.. Something like:
> >> >> >
> >> >> > chain(my_policy(result), default_policy)
> >> >> >
> >> >> > So that several converters can be tried even if you use a policy. 
> Am I
> >> >> > making sense here?
> >> >>
> >> >>Not yet.
> >>
> >>You gonna explain this stuff?
> >
> > Ok, I was just rambling about how compile time converters could
> > interact with runtime converters.
>
>Still very confused as to why you'd ramble about something that we're
>not doing  (?)

It isn't clear what we are doing yet.. Like I stated earlier, just trying to
keep the discussion open.

> > I should have named "chain" "composite" instead; it tries all it's
> > converters and returns a best match, just like the runtime system
> > does.
>
>Most confusing.

What is confusing here? Consider for just a moment that we had
compile time converters AND runtime converters, it would be
really good to be able to use both together. Consider a compile
time converter which handles conversions to const char* from some
type X. We also have a standard converter registered that handles this
conversion, so when we use our compile time converter policy
we want to try using the standard converter as well.

Here some sample code for a simple composite converter that
uses a converter generated both from my_policy and from the
default policy:

Just assume param_type is just a parameter in the interpreter
environment; PyObject* or whatever.

template<class T>
struct my_composite_converter
{
    typedef typename my_policy::template apply<T>::type c0_t;
    typedef typename default_policy::template apply<T>::type c1_t;

    std::size_t choice;
    c0_t c0;
    c0_t c1;

    int match(const param_type& param)
    {
       int r0 = c0.match(param);
       int r1 = c1.match(param);

       choice = r0 > r1 ? 0 : 1;
       return r0 > r1 ? r0 : r1;
    }

    T convert(const param_type& param)
    {
       switch (choice)
       {
          case 0: return c0.convert(param);
          case 1: return c1.convert(param);
       }
    }
};

---
Daniel Wallin



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf