Re: [pygccxml-development] Status of code inserters

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

Roman Yakovenko wrote:
> Does it mean that you agree with proposed name?

I've already started renaming the code blocks to function transformers. 
So yes, when referring to the general mechanism I have no objections to 
use the name "function transformers".

In pypp_api however, I will still keep the function setArgPolicy() for 
now as I believe this describes and documents better what the user is doing.

>> 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.
> 
> Can we put "thread safe" aside for a time being? We will come back to it.

Right, it's not a use-case for the function transformers anyway.

> So, the whole feature is to create plug-ins into ( calldefs ) code 
> creators?
> Nice :-)

I haven't seen it that way yet, but yes, it's a valid way to look at it. 
The function transformers correspond to plugins then.

>> 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".
> 
> This is the name I looked for! "substitution manager". One comment: do you
> mind to write full package and class names? We always can introduce aliases
> in Python. I think that full names are easy for maintenance.

ok, I'll rename as follows:

subst_manager_t -> substitution_manager_t
wrapper_subst -> wrapper_substitution

(It's just that there's usually a typo when I try to type 
"subsi^Htiut^H^Htui^Htion"... ;)

>> - 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.
> 
> I plan something different here: I want to associate include files with 
> classes

Sounds like a good idea!

> and other global declarations. Thus Py++ will generate better code( 
> right now
> all cpp files contains includes of the whole project ). This feature
> will work for our case too.

Yes, my above point is still the same though. The function transformer 
will just tell the code creator that it is going to create code that 
requires include file "strawberry.h" and now it's the code creator's 
responsibility to make sure that "strawberry.h" gets included at the 
right place. How this is done is up to the code creator, it may create 
another include code creator or it may use the new scheme from above.

Yesterday and today I have already done the following things:

- Added a property "function_transformers" to calldef_t (and while I was 
at it I already added the property "thread_safe" as well)

- I modified mem_fun_v_wrapper_t and mem_fun_v_t so that the function 
transformers are used. Now the code from the wiki (option 3) is created 
for public virtual member functions. So far everything looks fine, but I 
have a slight problem with Boost.Python's override. For example, we 
might have the following code:

   virtual void spam( int & n ) {
       if( bp::override func_spam = this->get_override( "spam" ) )
       {
           // The Python method will return an integer
	  n = func_spam();
       }
       else
       {
         Viking::spam( n );
       }
   }

This function will work and in this example everything is fine. But 
there might be other Python functions that return several values so the line

           n = func_spam();

doesn't work. So how can I invoke the function and just receive a 
boost::python::object object as result without that Boost.Python tries 
to convert it to a C++ value?

I tried the following which doesn't work:

           boost::python::object result = func_spam();

When I run this code I get the following error:

TypeError: No registered converter was able to extract a C++ reference 
to type boost::python::api::object from this Python object of type tuple

Any ideas?

- Matthias -