Re: [pygccxml-development] Code inserters/Arg policies

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

Roman Yakovenko wrote:
>> I have added a section "Summary" that contains the full code for option
>> 3 with additional comments:
>>
>> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Summary
>>
>> I have also slightly modified the code from option 3 so that now the
>> default_spam() method looks the same as in the initial version (i.e. it
>> doesn't need any code modifiers).
> 
> Two comments:
> 1.  May be I missed something, but it seems to me that registration 
> should also
>   contain Viking_Wrapper::spam, am I right?

Well, no. Or let's rather say, yes, it should, but it doesn't work. When 
I changed the signature of default_spam() on the original code generated 
by py++ I got compile errors. This was the reason why I started 
investigating other options.

Actually, I haven't found any documentation about this special version 
of the def() function in the Boost.Python reference manual (it's only 
mentioned in the tutorial), so I don't know the requirements on the two 
function references (but it seems that they must have the same 
signature). And I also have to confess that I don't fully understand how 
it works and what it actually does....

> 2. In C++ arguments by reference used as: in, out, in and out. May be
>   func_spam callable should take int and return int.

Oh, sorry, I didn't mention it but I was assuming the argument of the 
spam() function is an output argument. But you're right, if it was in or 
in/out, the actual code would have to look slightly different.

> Sorry I was not clear, multiple inheritance in C++. py++ creates wrapper 
> class
> for every class in the hierarchy. I am sure this will work. But still,
> I think it is worse to add such test case.

You mean a C++ class Norwegian that is derived from Viking and that is 
exposed to Python and that has to pass all the tests that Viking had to 
pass, right?

>> I think that should still be the decoration interface as already
>> mentioned here:
>> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Decoration
> 
> I see. What should be done with wrappers py++ generates? 

Eventually, I hope that those wrappers are generated by py++ (and not by 
the high level API) so that there will never be two conflicting wrappers.

> Do you wan to define
> "default policies" ? "Default policies" does not have to be a class,
> it could be just a terminology.

Well, if a function only has the "default policies" (=lack of any "code 
modifiers") it just means that there will be no additional code inside 
the wrappers that transforms arguments. But a user doesn't have to 
specify that explicitly, so I'm afraid I don't exactly understand where 
we need to define any "default policies"...?

>> That is, there should be at least one decoration operation that allows
>> me to attach "code modifier" objects to one particular function.
>> At this level the user doesn't even have to know about the problem with
>> non-pure virtual functions, it just works the same as with non-virtual
>> functions. Knowing about the details is only necessary when you want to
>> write your own "code modifiers".
> 
> I agree with the solution, but we will have to find better name. May
> be "policies" will be good enough?

Couldn't this lead to confusion because people might mix it up with 
"call policies"?

- Matthias -