Re: [pygccxml-development] low level vs high level API

[Allen B. <al...@vr...>]

Matthias Baas wrote:

> Hi,
>
> this mail is a general reply to the previous mails posted. I think 
> there's still some confusion among me and Allen about the last changes 
> to pyplusplus (module_builder_t, decl_wrappers, etc). So I'd just like 
> to mention a few points and check if we've already agreed on them or 
> if there are still different views (which may have led to the confusion):
>
> - The final version of pyplusplus will have two "separate" APIs, a low 
> level/internal API and a high level API. Is this already general 
> consensus?

I agree with this.

>
> - The internal API is what pyplusplus already had when I first tried 
> it out a few weeks ago. A user could just use this API and create 
> bindings. In this case, his driver script may be somewhat verbose but 
> he has full control over pyplusplus.

This is my understanding.

>
> - The high level API is a mere convenience for the user to express 
> things more concisely. This API refers to the internal API to 
> implement its stuff. Currently, Allen's pypp_api module constitutes 
> the high level API.
> If I've understood Roman correctly, I believe his new module_builder_t 
> and decl_wrapper classes should already be seen as high level API, 
> replacing pypp_api, right? 

I am confused about this as well.  It seems that these classes mix two 
ideas:
1. They provide some of the interface that my high-level API needs to 
modify they way creators are created (the injected flags patch I submitted)
2. They also seem to be attempting to draw in some (but not all) of the 
capabilities that we were talking about providing to the users in the 
high-level API.  It seems reasonable that there will be some duplication 
here because the high-level API will use some helpers in the low-level 
API but I don't think it is a good idea to keep moving things across to 
the low-level API.  I agree with Matthias's comments below about 
separation being a good thing.

> What I liked before those classes was the strict separation between 
> low level API and high level API. It was clear whenever I was using 
> something "low level" (a class with _t suffix) and something "high 
> level" (from pypp_api or initially also from my own version). This 
> distinction has become somewhat blurred and the high level and low 
> level stuff have become somewhat intermingled. As there is no 
> documentation yet, the only hint would be the sources themselves but 
> they don't provide any information whether something is considered to 
> be part of the low level or the high level API.
>
> So what I'm missing is documentation about the low level API that 
> Allen and I could rely on to experiment with various high level APIs. 
> Maybe some ideas will lead to modifications to the low level part of 
> pyplusplus but when I was creating my own API version I was quite 
> pleased to see that the previous internal API has already allowed 
> expressing almost everything I needed. So it was not that bad at all.

Agreed.  I like the idea of you and I refining and expanding the 
high-level API while we pepper Roman with ideas, requests, and 
refinements for the low-level API.  (and as my status update message 
describes I think one of the first things I would like to see is 
documentation and comments. :)

So summary, I agree with you Matthias.

-Allen

>
> - Matthias -
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>