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

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

On 3/13/06, Matthias Baas <ba...@ir...> 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.

I am a little bit surprised. I struggle with my self for 3 or more
weeks not to write
high level api. But this is okay. I have something like 10 hours in a
week to work on
py++. It would be nice to know how many hours do you have to work on
it, so we could
plan features. Also until end of this week I should have Internet
connection at home.
It will be easier to discuss our efforts.

Can you commit your changes? I would like to analyze your code, as I
did with Allen one. I am sure I can find some piece of code that
should be placed in an other place :-).


> 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 hope you read my post about adding some teaching/guiding functionality to
decl_wrappers. Did you created DeclWrapper base on my work or you wrote
something new? Also what is wrong with mdecl_wrapper_t class?

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

What is wrong with pygccxml.declarations.matcher? Even if you say that
search is always done recursively you still can use it. Am I wrong?

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

First of all I like you idea about using and\or\not for
matchers\select function.
Why did not you modify matchers? This is exactly how things should work.
I thought that the user will use lambda. But this is a great idea,
lets port that piece of
code to pygccxml.declaration.matchers object. I think I have an idea
how to do it
in single place. If you want we can discuss this in separate thread.

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

Good.

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

Good.

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

Global variables? -brrr :-). Can I propose solution for this? Can you
add all those
global variables as class members? No global variables + all instances will
behave the same.

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

If you would use my decl_wrapper class hierarchy you could put those
select functions on scope/namespace/class wrappers.

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

This is okay, We need something to comment/try.

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

Please commit your changes. Do not forget license. People should know
who is guilty :-).
I will try it with boost.date_time library.

Thanks

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