Re: [pygccxml-development] Status of code inserters

[Roman Y. <rom...@gm...>]

On 9/1/06, Matthias Baas <ba...@ir...> wrote:
> 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".

Matthias where is the code you are talking about? Do you want to create
function_transformers package under pyplusplus and move all relevant code
to it?

> > 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.

Finally I understand the feature. Thanks.

> >> 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"... ;)

You are not alone. This is one of the reasons I use properties every where.
If I see that my script does not works as expected I can put break point
in "get" and see whether it is called or not.

> >> - 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!

Thanks. I will implement it before next release.

> > 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.

My points are:

1. creating function transformer is a task that requieres user attention to be
    concentrated on types and function imlementation. Adding something
    else to it will disturb to the user

2. Py++ will have only one way to control included files from declarations.

We can discuss this point later. The first implementation could be done as you
propose. But I propmise you we will back to it later :-)

>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.

Only code creators factory creates them. In most cases code creators
does not know about each other.

> Yesterday and today I have already done the following things:
>
> - Added a property "function_transformers" to calldef_t

Do you mean decl_wrappers.calldef_t, right

> (and while I was
> at it I already added the property "thread_safe" as well)

Please, remove thread_safe. We will add this later.

> - 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?

Please commit all your code :-).

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/