Re: Re: Conversion policies

At 22:05 2003-08-27, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
> > 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!

At last. :)

> >> > 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.

Right, this is simple enough with a interface adaptor like the one you
mentioned above.

---
Daniel Wallin



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