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

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

Matthias Baas wrote:
> More policies can be defined as appropriate. For example, variants of 
> the InputArray/OutputArray policies could take the array size from an 
> additional argument.

Roman Yakovenko wrote:
> I'd like to add next example, from what you can see that argument
> policies should be able to deal with more complex case:
> 
> //read from some file
> int read( byte* buffer, unsigned int buffer_size );
> 
> This is very interesting use case for "argument policies", because we
> should deal
> with two arguments at the same time. The generated code will not be
> very different
> from code generated by using OutputArray/InputArray policies.

This is an example of what I meant with the above statement from my 
initial mail.
My current prototype allows that already. An argument policy isn't 
restricted to a single argument but it can deal with as many arguments 
as it likes.

The interface of the argument policy class has four methods that each 
policy has to implement:

- prepareWrapper(wm): This method can do changes to the signature of the 
wrapper function (like adding or removing arguments, for example).

- preCall(wm): This method has to return C++ source code that is put 
before the original function invocation

- postCall(wm): This method has to return C++ source code that is put 
after the original function invocation

- cleanup(wm): This method has to return C++ source code that contains 
cleanup code in the case an error has occurred somewhen after the 
preCall() code but before the postCall() code (which won't get executed).

The argumen 'wm' is an instance of a "WrapperManager" class that can be 
seen as the code creator for the entire wrapper function. It has some 
attributes and methods that can be used by the policies, such as:

- removeArg(index): Removes an argument from the wrapper function

- insertArg(index, arg): Adds a new argument to the wrapper function

- appendResult(varname): Adds a particular variable to the result tuple

- removeResult(varname): Removes a variable from the result tuple

- replaceCallArg(index, callstr): Replaces a variable that is used for 
the original function invocation.

- declareLocal(name, type, size=None, default=None): Declares a local 
variable and returns its actual name. To prevent name clashes, every 
variable that a policy uses must be declared.

For example, the Output class simply has to implement the 
prepareWrapper() method and only do three things:

- Remove the given argument: wm.removeArg(index)
- Declare a local variable that takes over the part of the input 
variable (the variable has the same name and base type than the original 
input variable): wm.declareLocal(name, type)
- Add the new local variable to the result: wm.appendResult(name)

> I want to say that "argument policies" feature should be rename. New
> feature should deal
> with an examples I showed. So it does not deal any more with single
> argument, but with
> whole function.
> 
> Bottom line - new name needed.
> 
> Suggestions:
> 
> [ function ] wrapper call policies
> 
> Comments?

At the beginning, I was calling them "argument transformers" and only 
later noticed that they were quite similar to "call policies" and then 
called them "argument policies" to express this similarity.
The main purpose of those classes is still to do something with the 
arguments (which includes the return value), so I don't see the 
necessity to rename them.

I'm against using "call policies" in their name because they actually 
have nothing to do with Boost.Python's call policies, so I think this 
would just lead to confusion.

- Matthias -