Re: [pygccxml-development] Current status...

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

Matthias Baas wrote:

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

Great.  I was feeling guilty that I got tied up with work this weekend 
and hadn't been able to get to this.  I am glad someone is making 
progress. :)

>
> 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
>
If you go ahead and check this in I don't think there will be chaos.  I 
think in fact that it would help us to better understand what we need to do.

On question I have related to this implementation though:

 From our discussion the other day I think it sounds like we don't need 
a DeclWrapper/MultiDeclWrapper class but instead should maybe be 
modifying/extending/renaming/etc the decl_wrapper that are being created 
by the pyplusplus code creator now.

I think this may be the direction to move because:

- It seems like this is what Roman wants
- The interface for everything but the query methods in *DeclWrapper 
will just call straight through to the pyplusplus _wrappers
- Using the pyplusplus wrappers could give us better type safety in the 
form of errors when the user calls something that doesn't make sense for 
the currently wrapped decl type.

Doing this would move a great deal of the high-level API into the 
pyplusplus decl_wrappers but it just seems like a good move right now.

Thoughts?

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

Sounds very interesting.  I can't wait to see it. :)

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

Sounds good.  Once this is all in there I think we can really start 
pushing the API and finding areas that we want to extend further.

>
> 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.
>
Sounds great.  Thanks for working so hard on this.

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