Re: [pygccxml-development] Future of pypp_api...

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

On 8/20/06, Matthias Baas <ba...@ir...> wrote:
> > I did not created another Pyste, Py++ will never be another Pyste.
>
> I think that's what Allen meant when he said that he (or rather, we) and
> you have different goals.

I am one of the biggest user of Py++. I have same goal as you.

> Of course, I do agree that creating bindings using py++ can be done
> faster and more "complete" (would I be using it otherwise?).
> But the reason why Pyste fails in this respect is *not* because its API
> concept cannot deal with those things, it's rather that its backend is
> not as powerful as py++.

I don't agree with you. Pyste always works with single header file.
I am almost sure, that is not possible to extend Pyste API to work on whole
project.

> I think its API concept is pretty easy to grasp
> and more intuitive and easier to use than py++. So the ideal solution
> for me (and I suppose for Allen as well) is having the API concept from
> Pyste in combination with py++ as its backend. Basically, this is what
> pypp_api is trying to accomplish (and so far, I'm quite pleased with it).

Your situation is not different from my. I am not pleased with pypp_api,
but I do pleased with Py++. But still I am willing to work on this.

>
> As pypp_api was created by Allen and me, I guess you can simply have a
> look at it to see our "suggestions".

May be I missed something, but Py++ contains all non problematic functionality
found in pypp_api.

> I consider the functionality from pypp_api (or in your case
> module_builder_t + related classes) to be the high level API.

related classes are: decl_wrappers + pygccxml.declarations, right?

> > 2. This will never work. He should know at least what is declarations
> > and declarations tree ( pygccxml.declarations package )
>
> He only has to understand the concept, but not the details (how to
> traverse the tree, the exact types of the nodes, etc.). The high level
> API already provides an interface to deal with that tree.

May be I miss something, but ( I am not arguing here but ask you to point me
to the mistakes )

1. Where I force him to know how to traverse the tree?

2. Why do you think that user should not understand on what declaration set
    he is working on?

> >>     * Provide access to all the power of pypluplus and pygccxml *if* the
> >>       user wants it
> >
> > What do you mean? To introduce 3 module builders ( beginner,
> > intermediate and power user ) ?
>
> No, for example in the case of pypp_api you can obtain the declaration_t
> objects that belong to a particular query result. In most cases you
> don't need them because you can use the API provided by pypp_api, but
> should there be a case where this API is not sufficient, you have the
> option to "go down" and work directly on the py++ declaration objects.

Can you point me to the user code, I want to be sure I understand you right.

> Another example is the code creator tree. Usually a user doesn't need
> this tree and doesn't even have to know that this tree exists, but
> should there be a case where a user has to inject his own code creators
> he can do so by intercepting the code creator tree generation and do his
> own modifications to it (using the "low level" py++ interface) before
> pypp_api proceeds with writing the files.

It is not completely true. User should understand, that after some
point he can not
work on declarations. pyplusplus.module_builder_t class explicitly defines this
point.

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