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

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

On 4/18/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
> So my suggestion is to introduce something similar to call
> policies, that's why I called it "argument policies". The idea is just
> that for each "problematic" argument you specify that it needs special
> treatment.

I like the idea and the name you gave it. It is easy to understand and expl=
ain.
I think, this will be the focus of next release.

Before we proceed to technical details, I suggest everyone, who is
interested in this
should review two code creators: function_t and function_wrapper_t
within code_creators/calldefs.py file.

> I have already implemented a prototype version of this in the
> experimental module. So far, it has worked quite fine for my Maya
> bindings (by the way, I have just released a first "preview" version of
> those bindings, so if anybody wants to have a look how I create them,
> have a look at the 'maya' package over here: http://cgkit.sourceforge.net=
/)

:-). I will definitely take a look. It seems that we can start "who is
using pyplusplus?" list.
Who does want to contribute :-) ?

> Currently, my implementation would not work when a class already
> receives wrappers generated by pyplusplus. But I think this could be
> changed so that the wrappers created by pyplusplus use the same
> framework for specifying wrapper source code (but this needs
> modification inside pyplusplus).
>
> The above argument policies use the same "code creator" concept that
> pyplusplus already uses, the interface of those code creators is just
> different because there are actually two places where code can be
> placed, either before or after the original function invocation. And in
> addition to creating code, those special code creators can also modify
> the signature of a function. So pyplusplus would have to use those
> special code creators instead of just creating one static block of C++
> source code for the entire wrapper function.

Right

> Any comments? Do you already see cases where this could not work or how
> it could be improved?

I hope next week, I will write some PEP. Now I just want to comment the fea=
ture.

Please take a look on the classes ( function_t and function_wrapper_t ).
They are tightly coupled and contains code that treat a lot of use cases:

When generating code pyplusplus should consider

1. [ virtual | pure virtual | not virtual ]
    Different code should be generated for different access types/

2. [ public | protected | private ]
Yes, private pure virtual and private virtual functions should/could
be exposed. See
"template method" design pattern.

3. [ static | free | member ] functions

4. operators( call (), index [] and may be something else  )

5. class hierarchy with deep more then 2 abstract classes:

struct base_abstract{
void do_smth() =3D 0;
};

struct middle_abstract : public abstract{
void do_smth_else() =3D 0;
};

Class wrapper that is built for middle_abstract should define also
"function wrappers" for
do_smth function. I can explain, why but lets leave it.

6. function return value: for example virtual function, that returns
reference to some object,
could not be overridden from Python - access violation is guaranteed.

7. template functions on broken compilers ( msvc 7.1 )
    When your expose some instantiation of template class that has
template function
    pyplusplus should define few typedefs in order to generate code,
that takes address
    of the function. It does do it right now, but this should be fixed.

8. difference between fundamental types and user defined
   ( boost::ref and boost::python::ptr ).

I am sure this is not the full list. Now we should add here argument
policies. This is not going
to be easy. I see few challenges here:

0. simple user interface

1. orthogonality, it is obvious to me, that our solution should be
constructed from
    few blocks

2. use cases enumeration

3. implementation

4. testing

It is not going to be easy, but we will have a lot of fun, I am sure.

Contribution: we can start now to create comprehensive unit tests for this.
It would be grate, If some one can write C++ code that will cover all
those use case.

> - Matthias -

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