Roadmap? (was: Re: [pygccxml-development] Printing declarations...)

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

Roman Yakovenko wrote:
>> I noticed that the selection works differently in your version compared
>> to the experimental version. I would have only called it "stable" when
>> the interface in both versions would have been identical as in this
>> case, it would have shown that we all agree on one common scheme.
>> Obviously this is not yet the case.
> 
> Why? In my opinion our "select" interfaces are very very similar.
> What I am missing. I do aware about differences in regex filter/matcher, but
> that's all.

In the date_time example you're very often using lambda functions to do 
selections. The function is passed as first argument (without using 
keyword arguments), but sometimes you also just pass a string with the 
declaration name as first argument. So obviously there is some builtin 
rule about what the argument types may look like in your version. The 
experimental version doesn't have that. So far, it is only guaranteed 
that the first argument is the name filter, all other filters must be 
specified by keyword arguments. Actually, I haven't found out yet what 
arguments your selection functions do provide (the source code is not 
that easy to read)...

>> So switching entirely to
>> your version would take quite a bit of time and even with my current
>> partial script I've noticed things that could be improved in my opinion.
> 
> What are they? 

 From the top of my head:

- There's no single module from which the user can import all the 
required stuff but instead he has to know where everything is located.

- The module builder still requires the config object (which I would 
rather regard as an internal pyplusplus object).

- The selection functions accept *any* keyword argument even when that 
argument is not used/valid at all.

- I think making the step to create code creators explicit is not 
necessary. To me, code creators are rather an implementation detail a 
user doesn't really have to know about (maybe this will change with more 
advanced features...?). Apart from that, the error message that appears 
when a user forgets to do this step (as happened with me :) is confusing:

"self.module is equal to None. Did you forget to call create_module 
function?"

The first sentence refers to an internal variable the user does not know 
about and the second sentence refers to a function that does not exist.

- When I wrote the source files without doing any decorations I got an 
empty module. So far, so good, this has been the test to check whether 
declarations are ignored or exposed by default. But when I added 
include() calls for some particular classes, I actually got many more
classes in the output (that I didn't want).

- There are no doc strings... ;-)

> We can discuss them in few mails and I think we could implement
> them on main branch.

But if you would now implement everything so that it conforms to my 
opinion, then you would basically end up with the experimental module. 
So what's the point of doing that? We have that already.
Instead we should try to get the core of pyplusplus stable and flexible 
enough (one area which I still think is a weak point in pyplusplus is 
the ability to customize the individual output files. I still don't know 
how/if I could add source code at the declaration level in a particular 
output file or modify the include files from one particular file).

>> and hopefully we can objectively
>> balance the pros and cons of each version once they're in a state that
>> the respective supporters are happy with. :)
> 
> That is exactly what I want. I think you and I developed enough. It is a time
> to move on. I think we should sit and merge our sources/ideas.
> Do you think that there are some major features that is still missing
> in my/your selection code base?

So far, I have been fine with the selection in the experimental module. 
But I guess some more filters could be useful eventually. And the 
performance could be better, of course. :)

But there are certainly features missing in the API. See for example, 
the section "What capabilites are not supported by the current API that 
we should have?" in the wiki.

> Matthias, I want people to start using pyplusplus. 

I see that you're eager to get out a new release, and this is fine with 
me. :) But what's the problem with releasing pyplusplus and referring to 
the experimental module which the people can try out and provide 
feedback? This is not going to be the 1.0 release, is it? ;)

> code. What do you think about next plan: this and next week you are
> going to develop
> missing functionality.From the 1/04 we close experimental branch and
> start merging almost all functionality to main  branch.

I cannot guarantee that in a week or two the experimental API will be 
finished. Actually, I'm pretty much sure that it won't be finished by 
then as there are still a lot of areas we haven't addressed yet.
For me, one of the next things I'd like to see would be automated 
wrapper generation.... but this is an entirely new thing that I don't 
know yet how this could be done (and if it could be done at all). It's 
just an area that needs some experimentation... :)

So how about the following instead as the next milestone for pyplusplus:

"Get the core of pyplusplus stable and flexible so that *any* high level 
API could be implemented on top of that without having to modify 
pygccxml/pyplusplus"



- Matthias -