Re: [pygccxml-development] Status of code inserters

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

Roman Yakovenko wrote:
> * I think we should give a name to the feature. I propose
>   "Function Transformation".
>  This is basically what we do.

In my current implementation the "base" class for the "arg policy" 
objects is called code_block_base_t. But something like 
func_transformer_t or similar is fine with me as well. After all, this 
class is more or less an internal class that doesn't have to be used by 
the end user, its main purpose is to document the interface that the 
user has to implement.

As to the name that is exposed to the user, in the wiki and doc strings 
I'm still using the name "argument policy" as I found it still describes 
the main usages best. All the cases where I want to use this feature for 
my Maya bindings deal with arguments (including the return value = 
output argument), see the use-cases in the wiki. Previously, the only 
exception would have been the thread-safety stuff, but meanwhile I think 
this should not be implemented using the "arg policy" mechanism anyway 
because this is not straightforward to do. Instead, I'd recommend to 
implement that separately.

> * Untill this feature, the only classes that generate code were code 
> creators.
>   Py++ design\architecture is described here
>   ( 
> http://language-binding.net/pyplusplus/documentation/architecture.html ).
>   I prefer to stay with it, hence I ask you how you see this feature
> is integrated  within Py++.

The existing Py++ calldef code creators will still remain the code 
creators for the calldefs. What would slightly change is the way *how* 
they create their code, i.e. they would have to add some variables at 
appropriate places to the code and have that variables substituted by 
the proposed text substitution services.

> * WrapperManager. It is presented in the document as a "Template" class. 
> From my experience it is not possible to build such class without using
> tons of if-else statements.

What do you mean with "Template" class? Are you referring to the 
template string argument that is provided by the user of the class? 
(this is just an argument name)

> * Coding convention. I really don't want to introduce

Uhm, to introduce what?
I already tried to stick to the Py++ conventions.

By the way, yesterday I renamed the "wrapper manager" class and now I'm 
calling it "substitution manager" class. I think this describes the 
functionality better. The actual class name in the implementation is 
"subst_manager_t". The entire sub-package is currently called 
"wrapper_subst".

> I propose to begin to work on the feature.
> 
> * To create C++ code and Boost.Python expected code. Thus we will see
>   examples and the goal. Also I think it will give us better understanding
>   of the subject.
> 
>   I can write do this.

ok. See the wiki for use cases. At least for the "wrapper" part, I am 
already using code in my Maya bindings for quite a while now. Its just 
that I couldn't test the "virtual" part yet.
For testing the new implementation I have already a "new-style" Output 
policy.

> * To create design. I'd like to see classes and methods, with 
> responcibility
>  description. This will give us an ability to split the work. Also we
> will be able
>  to take a use case and to see what code user will have to write in order
>  to apply a transformation.

At the lowest level, there is the substitution manager class (formerly 
known as wrapper manager) which has to be used by the Py++ code creators 
to "enhance" their generated code (see the wiki for examples). Some 
things to note here:

- The modified code might require additional include files. The caller 
(i.e. the Py++ code creators) must ensure that these include files 
actually get included.

- There might be some additional support code necessary that is 
generated by the substitution manager. But I think this can probably be 
handled much in the same way as the previous point, so it's not really a 
new point.

- The modified code (at least the wrapper) might have a different 
signature than the original code. The Py++ code creators have to deal 
with this. In particular, it might happen that two overloaded functions 
end up with the same signature.

- The user might add "arg policies" to methods that wouldn't have 
spawned a wrapper function otherwise. So the presence of policies is 
already a sufficient condition for the creation of a wrapper function.


I have already implemented the substitution sub-package (see the wiki), 
but the integration into the Py++ code is not yet done.


- Matthias -