Re: Re: [C++-sig] [Implementation] Calling wrapped functions, converters, policies

At 22:43 2003-09-17, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > At 18:39 2003-09-17, David Abrahams wrote:
> >
> >>I think we need to stop using the term "policy" without qualification.
> >>It gets too confusing.  Every time I do it, I mean CallPolicy (as in
> >>Boost.Python).  I think when you do it you mean ConversionPolicy.  In
> >>fact, why don't we say "[argument|result] [to|from]_xxx converter
> >>generator" for what I called ConversionPolicy?
> >
> > Agreed. We still need to settle what a CallPolicy and converter generator
> > actually is though. :)
>
>
>I think a FromXXXConverterGenerator is a mixed compile-time/runtime
>function object which produces a converter type.

Hm ok, what would it do at runtime?

> >>As a matter of fact I think many static from_xxx converter types will
> >>want to wrap the default converter with additional behavior, so their
> >>state will need to include the postcall chain anyway.
> >
> > Yeah, I don't know how that would work. :|
>
>Derivation or aggregation are obvious approaches.

Right. I was referring to the state object though, and how that could be
shared even by converters that are aggregated by other converters.

> >> > ConverterPolicy is also a model of CallPolicy
> >>
> >>Noooooo!  At least, not the way I understand it.
> >>
> >>CallPolicy is the Boost.Python concept that includes pre- and
> >>post-processing of the native interpreter argument tuple.
> >
> > Ok, your view of CallPolicies is the same as mine. It's just that I think
> > of the converter generators as a model of CallPolicy as well.
> >
> > I wanted the converter generators to have precall/postcall functions
> > as well, since that would enable the "dynamic postcall action chain"
> > thing in default_generator.
>
>Hmm.  Part of the point of using the "dynamic postcall action chain"
>is that dynamic converters *don't* pay for a postcall action unless
>they need one, which is rare.  Of course they could register a null
>postcall function pointer, which would incur a test/call sequence for
>each argument, as opposed to a single test/call for the whole chain.
>Under that scheme, dynamic (default) converters don't need a postcall
>action, because the CallPolicies' one postcall chain handles
>everything.

Right, the state would be shared between all converters that are
generated from the same generator, so we would end up with the
same result. (only one postcall chain)

> > In that case the default generator would generate an appropriate
> > converter and pass it's state to the convert() functions, which can
> > add postcall actions to the chain. When we call postcall() on the
> > generator, it could call it's chain..
>
>Oh, that's scary.  You want to actually instantiate one of each kind
>of generator object.  Well, I understand what you're up to, but I
>don't think I agree with the implication that converters generated by
>different generator types can't share any state.

Ok, but how could they possibly share state? Different generators/call policies
need different types of state, don't they?

> > I guess default generator could model both a generator and CallPolicy
> > instead though.
>
>Instead of what?  How is that different from what you've been
>proposing?

Instead of letting the generator concept have precall/postcall.

>AFAICT, too many concepts are getting collapsed together here.  Can
>we try to draw more distinctions?

Absolutely. I'm not sure where to start though. :)

> > BTW, in luabind the converter object also has precall/postcall actions.
> > This can be very useful. For example, they are used in out_value_policy,
> > which can handle T* and T& which are meant to be out values.
>
>The thing I dislike about that is that converters get used in non-call
>contexts where "precall" and "postcall" are nonsense.

Yeah, maybe we need another converter concept?

> > void f(int& x); is treated like int f_wrap(int x) { f(x); return x; }
> >
> > Here the postcall function in the converter is used to convert
> > the result back to lua.
>
>Seems to me like the wrong way to do things.  IMO the result converter
>should be responsible for that, but it should have access to the
>argument converter in order to do its job.

That implementation seems far more complicated. Also I don't see what's
wrong with using the postcall.

Note that it can be used like this:

   void f(int& x, int& y);

   def("f", &f, pure_out_value(_1), pure_out_value(_2))

   x, y = f()

How could this be handled by a result converter?

> >> > with the additional nested template type 'apply' which generates a
> >> > converter type.
> >>
> >>In that case, what's the concept you have been calling "CallPolicy?"
> >
> > Same as you, something that has precall/postcall.
>
>I still don't think that's quite the same as my concept.  My
>CallPolicy also has a result (but not argument) converter generator.
>I thought when that concept changed I would end up adding all the
>argument converter generators.  In other words, it's the whole wad
>required to actually build the wrapped function.

Ok.

> >>I think we're having a problem with terminology.
> >
> > Yeah, that and my ability to express myself. ;)
>
>Well, I'm beginning to understand what you're driving at, but I'm
>still not comfortable with it.  It seems very general and abstract
>still.

Yeah, lets keep the discussion going and I'm sure we'll end up
with something really nice. :)

---
Daniel Wallin



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