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

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

On 8/6/06, Roman Yakovenko <rom...@gm...> wrote:
> On 8/6/06, Matthias Baas <ba...@ir...> wrote:
> > Hi,
> >
> > I've just updated the "Code inserters" page in the wiki and added a
> > section about non-pure virtual member functions:
> >
> > https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Non_pure_virtual_member_function
> >
> > The new section examines how the Boost.Python code would have to look
> > like to be able to wrap non-pure virtual functions that have a signature
> > that is not compatible with Python.
> >
> > Any comments so far?

I like very much the way you did it.
One question: it is not clear how is registration will look like?

> Are there any use-cases I have forgotten? Are there
> > other options how this could be implemented?

There is one more test I'd like to see: multiple inheritance.

Also, it could be nice to see, how this policy plays well with other.
For example,
return status as exception.

> > The next question (which the text does not deal with yet) is how to
> > accomplish this using pyplusplus. The current proposal of a "code
> > inserter" API is not able to deal with such things yet (not even with
> > pure virtual functions), so this API still needs modifications.

I think it is too early to discuss implementation details. In my
opinion the document
you wrote is missing one section: usage example.

mb = module_builder_t( ... )

spam = mb.member_function( '::Viking::spam' )
spam.what I should write here in order to get the desired effect

May be the right question to ask: what user interface decl_wrapper
should provide?

> > Another question is whether pyplusplus should always create the code
> > from option 3 or if the user should be able to specify that some
> > use-cases are not important and it is ok that pyplusplus creates the
> > simpler code. (So far I would tend to use option 3 in all cases as it is
> > the most general option and I don't think it has a noticeable
> > performance penalty).

This is an experimental feature. In my opinion first we should see how
well it works
and only then to make it more customizable. So, I agree with you.

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