[pygccxml-development] Current status...
Brought to you by:
mbaas,
roman_yakovenko
From: Matthias B. <ba...@ir...> - 2006-03-13 18:47:40
|
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 - |