Re: [pygccxml-development] Feature proposal: "Argument policies"

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> Okay lets see if I understand you right.
> 
> class wrapper{
> 
> return_type function( arguments ) <== here user can modify function signature
> 
>     variables <== here user declares few variables and can bind them
> with arguments
>                           and/or return value
> 
>     make "native" call ( mix of variables and arguments ) <== here I
> think he should
>                          be able to bind return argument to some variable
> 
>     construct return value  <== here user can check result of "native" call and
>                          throw exception or construct return value.
> 
> }

I think you mostly got it. Just to clarify, here's the basic layout of 
the wrapper functions as they are currently generated (assuming there 
are n argument policies):

return_type wrapper_function_name( [self,] arguments )
{
   <local variable declarations>

   <precall code 1>
   <precall code 2>
   ...
   <precall code n>

   result = original_function( args );

   <postcall code 1>
   <postcall code 2>
   ...
   <postcall code n>

   return single_result_or_result_tuple;
}

- By default, the wrapper function has the same signature than the 
original function but the argument policies can modify the signature. 
When the function is supposed to be a class method the "self" argument 
is added as first argument.

- When more than 1 result variables get registered the return type 
automatically turns to "boost::python::tuple" and the return statement 
becomes a "return boost::python::make_tuple(args)" statement.

- The local variables are those that the arg policies have declared + a 
variable for the original return value (if there is one).

- The argument list for the original function call is a list of variable 
names. The arg policies can modify this list to "redirect" input or 
output (this includes the name of the result variable).

> If so, what interface you give to the user? Direct access to the code creator?
> I am not talking about wm.declare_local( ... ), as for me this is too
> low-level.

Policies that are independent of a particular project (such as Output, 
OutputArray, InputArray, etc) can be made part of pyplusplus and a user 
can use them for his own project. In this case, the user doesn't have to 
know how argument policies work internally.
If the standard policies don't fit the bill of the user, he has the 
option to write his own policies. Now the user must be familiar with the 
internals of the policy mechanism.

> Small comment about clean_up( :-) ) state.
> In C++ developers can use RIIA technique. So I think, that clean up
> state is nessecary. 

Should that read "is not necessary"...?

> I don't want to force developers to use it, but I
> also don't want to provide "too mach" help with hand written clean up actions.

What do you mean? Are you for or against the cleanup() method? (by the 
way, currently I don't have this implemented yet anyway as my current 
policies don't need any cleanup. But as soon as you have to allocate 
memory it might get necessary)

- Matthias -