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

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

On 3/6/06, Allen Bierbaum <al...@vr...> wrote:
> >
> > - 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?

Allen, your pypp_api is the only high level api. I created my class
for testers only.

> 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 submitte=
d)
> 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. :)

This is exactly what I did:

1. You needed decls printer, right? You wrote it. This was greate
piece of source.
    I put it within declarations and declarations wrappers

2. You needed some search algorithm with power of customization of
search criteria, right?
   I took Matthias ideas and some code and added it to pygccxml.declaration=
s
   The first place user will look at, in order to see how can he find
some declaration, am I
    wrong?

3. You needed multi-declaration wrapper, right?
  It took me few days to find out how can we use Python, in order to
provide best
  implementation to the class.

I think that I am not able to design high level API. So please, please
go ahead and do it.


> -Allen

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