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

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

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

I see. We will have to get support from boost.python developers.

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

Yes.

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

You just defined them. Also as I said, "default policies" is not a
class, but rather a
behaviour of py++, in case user did not set policies.

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

I forgot about it. May we think about "call policies" as another policy?

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