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

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
>> IMHO this is a shame because the pypp_api much better addresses the
> ------------------------^^^^^^^^^^^^^^^^^^^^^^^
> 
> I don't think so. Please define "much better", what do you  mean?

While we're at it, could I also ask you to do the same thing in the 
opposite direction? Which are the areas where you think the Py++ API is 
better than pypp_api? And what were the reasons to start a new API 
instead of working on pypp_api (considering that the Py++ API borrowed a 
lot of concepts from pypp_api)?

>> needs of keeping things simple and making Py++ approachable for new
>> users and users porting over from Pyste.
> 
> 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.

> Pyste failed to solve real world problems. The projects that use Pyste do not exist!

I don't think these statements are true. In my case, I know another guy 
who also did Python bindings for Maya and who was/is using Pyste. His 
project isn't public but it is used internally at the company he's 
working for. So Pyste was definitely used for a "real world problem".
Just because those people might not read the c++-sig mailing list 
regularly or have no time to respond to messages doesn't mean that Pyste 
is not used.

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

>>     * Optimize the time it takes to create the final bindings for a
>>       given C++ library.
> 
> I asked you to provide me with profiling information. All projects I
> has run under 3 minutes
> and generates more or less 1000 files.

Oops, as I was the one who added the above point to the wiki, I have to 
clarify something here as I now notice that the point got misunderstood!
I was not referring to the time it takes the *computer* to run the 
script, I was referring to the time it takes the *user* to write the 
script in the first place (which not only involves the API itself, but 
also documentation, warning/error messages, etc.).

>>     * Provide domain specific language so users can focus on their code
> 
> I am open for suggestions. Please write the paper, like Matthias did.
> Thus we will work
> together on it and I promise you after we get to agreement I will implement it.

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

>>     * Do not require the user to know anything outside of the high-level
>>       API to accomplish most tasks.
> 
> 1. Please define high level API. I don't know what you mean.

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

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

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

  - Matthias -