Re: Conversion policies

Daniel Wallin <[email protected]> writes:

> No, my point was that the same type can sometimes have different meanings.
> A* can be treated differently, a null terminated list of A's or a
> pointer to an A.
> In these cases it is important to override the default converters, since they
> would actually result in a core dump.

I see.

>>I don't like the term "compile time converter", because its work is
>>not done at compile-time, and because I'm still not willing to give up
>>on matching other converters as a fallback even for these cases.  

Scratch that.

>>I would prefer "explicit converter", because IIUC the programmer is
>>explicitly requesting a particular conversion mechanism.
>
> Yeah I don't like the term either, but it's hard to think of good names. :)
> Explicit converter sounds good though..

Agreed.

> See my example above for cases when you don't want to use other
> converters as fallback. In the general case you want to though.

Agreed.

>>The above makes little sense to me.  I am assuming that all explicitly
>>requested converters will use the registry chain as a fallback; is
>>there really a case where you want to promote *two* different
>>converters for a single argument in preference over the conversions
>>that are already registered?
>
> I guess it's not very likely that you would want two explicit converters,
> but like I stated earlier I don't think you _always_ want the registry chain
> as a fallback.

OK, already! ;-)

>>BTW, I think I need to be convinced that there's a role for "best
>>match" from_xxx converter selection.  Remember, a from_xxx converter
>>typically works on a single Python type (or a small range of Python
>>types) and produces a single C++ type.  It is fairly uncommon to
>>*ever* have more than one conversion for a single C++ type in the
>>first place.  I believe that registry scoping is mechanism enough for
>>prioritizing converters.
>
> I need to be convinced too. :) My current vision is that we choose the
> first matching converter and the best matching overload. 

Good, mine too.

> I also came to the conclusion that it is so uncommon to have several
> converters that can convert from the same python/lua type that it
> isn't worth it.

Yea! Agreement!

>> > I'm not sure what you mean by "converter interface" here. This is the
>> > current converter concept:
>> >
>> > template<class T>
>> > struct converter
>> > {
>> >     int match(param_type);
>> >     T convert(param_type);
>> > };
>> >
>> > Or do you mean the policies should build an actual lvalue/rvalue chain?
>>
>>What I think of as the converter interface is the signatures of the
>>functions which get registered,
>>c.f. boost/python/converter/convertible_function.hpp,
>>boost/python/converter/constructor_function.hpp.
>
> Ok.
>
>>Yes, I do appreciate how nasty that interface can be for people who
>>need to write them; we may want to provide friendlier but
>>potentially-less-efficient high level mechanisms for people who want
>>to define their own converters, e.g. an interface-transforming wrapper
>>template (c.f. boost/python/converter/as_to_python_function.hpp) which
>>produces the neccessary interface from a converter concept like the
>>one you've outlined above, or from a converter which dynamically
>>allocates its result (for expensive-to-copy types).
>
> I don't understand what we have to gain in making policies work with
> this kind of restricted interface though. If the user has chosen an
> explicit converter, why can't we do the work at compile time?

Hmm, good point.  I can think of only one advantage: users will have
the same interface for defining custom user-defined converters and
explicit converters.  I think there may be other ways to achieve
that, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



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