Re: [pygccxml-development] Re: recent changes to pygccxml\pyplusplus

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

Allen Bierbaum wrote:
>>> Accepted, but in future we will replace print statemnet with logging 
>>> module
>>>   
> Sounds good.

Sounds good to me as well.

>>> - Decl Decorator
>>>
>>> Not accepted. I created declaration wrapper for every declaration. See
>>> pyplusplus\decl_wrappers, But decorators is much better name. Should
>>> we rename them?
>>>   
> This seems like a lot of code to accomplish something that really 
> amounts to having a 4-5 flags per declaration.  I can live with the 
> implementation but it seems like overkill IMHO.

I agree with Allen, this looks fairly complex. Is this supposed to be 
the standardized low level API that Allen's version should use 
internally or is this already supposed to be the high level API 
replacing our previous versions?

>>> New classes that derives from declaration_t class.
>>> Every derived decl_wrapper has relevant properties for customizing code
>>> creators\module_creator.
>>>
>>> All code creators properties it is just an redirection to decl_wrapper
>>> properties.

The latest changes confused me quite a bit. It seems pyplusplus 
currently is under heavy restructuring (source code layout and already 
existing interfaces) which isn't easy to follow for me and which 
currently breaks my "driver" script for creating my bindings (that's 
what I meant the other day on the c++-sig list when I was against 
exposing the entire internal API as public API because the chances a 
future pyplusplus version will break a user's script are much higher 
then. And here we are... ;)
And while I'm all for consistent coding guidelines I currently find it 
quite confusing to have several different classes with the same name (I 
spotted at least three different classes called "class_t"). For me, this 
doesn't really help understanding the code.

>>> pygccxml:
>>> For every declaration class I am going to add *_matcher_t classes.
>>> This will help
>>> user to find declaration by type using some predefined criterias.
>>>   
> Can you give some example of this?

Yes, what will the interface look like and what do those matchers return?

(Maybe it would be a good idea to add a fictitious FAQ to the wiki that 
contains some tasks and how this should be done with an "ideal" API. 
This could then serve as a "checklist" to test new API proposals against)

By the way, I've started adding some stuff to the discussion page in the 
wiki. As I've never used a wiki for this kind of collaborative software 
developement yet, are there any guidelines or rules about how the issues 
should be layed out or how and what information is to be added?
I also still have to reply on some stuff in the c++-sig list, I just 
wondered if I should add those replies right to the wiki or do so by 
mail (and I need some more time to do so. Replying to all the stuff and 
getting the current stuff to work has become rather time-consuming 
lately...)


- Matthias -