[pygccxml-development] Current status...

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

Hi,

I implemented some stuff today that mainly deals with the selection of 
declarations (all additions are beneath the experimental directory, but 
I didn't commit anything yet). It's not finished but I just wanted to 
keep you informed about what I'm currently doing.

What I did:

- I implemented an alternative version of the 
DeclWrapper/MultiDeclWrapper classes

- To prevent chaos I didn't actually change anything in pypp_api but 
implemented the new DeclWrapper in a separate module and replaced the 
DeclWrapper in pypp_api at runtime

- I only dealt with the selection so far, so the decoration still works 
as before. The heart of the selection is a single function select() that 
takes as input the root of the pygccml declaration tree and a single 
filter "function" and returns a list of declarations that matched the 
filter. Conceptually, the search is always done recursively. The filter 
function is actually a special object which itself can be a tree of 
filter functions (think of it as the tree representation of a boolean 
expression). The nodes of the tree are the functions AND, OR, NOT and 
the leaves are the actual filters similar to what I had before or to 
Roman's matcher objects. Filters can be concatenated using the regular 
&, | and ~ operators. This select() function is supposed to be the most 
generic selection function that all specialized selection functions can 
be based on.

- Based on the above select() function there are the query methods 
(still using the naming convention from pypp_api):

   * Class / Classes
   * Method / Methods
   * Function / Functions
   * ...etc...

The first version will always reference exactly 1 declaration whereas 
the second version may reference an arbitrary number of declarations (if 
desired the user can still add an assert_count argument).
There is a global option that controls whether queries producing no 
results should be considered an error or not (for both cases). By 
default, empty queries are considered an error.
What I still have to do is make the above queries only work on the 
direct children of the parent node by default. I think this can again be 
done by a global option as default value which can be overridden by a 
local recursive argument.

There's no special treatment of overloaded methods yet. This is still an 
unresolved issue.

I hope that this version meets most (if not all) of the requirements we 
had so far. By default, the queries are local and the "1-result" version 
guarantees that you will get exactly one declaration. This is what a new 
user will see first. Then, when he feels bold enough he can use the 
"n-result" queries and can opt to enable global searches. If desired he 
can also turn off the checks for empty results.
In any case, the decoration interface is the same, so when the beginner 
gets advanced he doesn't have to learn a new interface.


- Matthias -