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

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

Roman Yakovenko wrote:
> Those decl wrappers should be used as high level interface for user to configure
> code creators. It does not really make the different how it implemented inside.
> In our versions it is possible to say
> 
> mb = module_builder_t(...)
> mb.namespace( ... ).ignore()
> 
> module_builder_t I created it is just proof of concept: I wanted to
> see that what you
> ( you and Allen ), could be implemented and that it really simplifies
> user interface.

Just out of curiosity, have there been any problems in getting our API 
versions to run? (as the above is just what Allen's version provides, 
just with different names) I noticed myself only later, that my version 
depends on a directory called "tmp" being in the current directory....

> In short I want you and Allen concentrate your efforts on user interface:
> class module_builder_t and multi decl wrapper and I will serve you as programmer
> who provide you all functionality you need. Do you agree?

ok

However, apart from that I was implementing a new cache class as 
mentioned in another mail. It's not yet finished because of that "dict 
vs list" bug in the handling of the "included_files" parameter. This 
first needs to be resolved before I can finish the class (so is 
source_reader_t.__parse_gccxml_created_file() supposed to return the 
files as a dictionary or as a list?)

>> 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... ;)
> 
> :-(. I tested my changes. They should work as is without any changes
> from user code.
> It seems that I introduce a bug.

It seems that for your tests you're using pyplusplus right from the 
source tree (instead of building/installing them using distutils), is 
this correct? You added some new sub packages to pyplusplus but forgot 
to add them to the setup script (decl_wrappers, module_builder). So 
anybody who's installing the package will miss those sub package and 
then, of course, pyplusplus will raise an exception right at import time 
(btw, obviously the cyclic thing I mentioned in the mailing list was not 
the source of the exception)

And the things that broke my script were:

1. call_policies.py was moved to a different location (so my import and 
usage was failing).

2. The recursive flag was removed from the module_creator.creator_t() 
constructor which broke my instantiation of that class.

I fixed those in my script so it wasn't a big deal, especially when 
considering that pyplusplus is still under devlopment (but it sort of 
confirmed my previous concerns... ;)

But even after fixing all of the above, there still seems to be a 
genuine bug which still prevents me from generating the bindings. When 
executing my script, I get the following traceback:

   File "pyplusplus/module_creator/creator.py", line 54, in __init__
     self.__decls = self._filter_decls( self._reorder_decls( 
self._prepare_decls( decls ) ) )
   File "pyplusplus/module_creator/creator.py", line 68, in _prepare_decls
     decls = filter( lambda x: not x.ignore, decls )
   File "pyplusplus/module_creator/creator.py", line 68, in <lambda>
     decls = filter( lambda x: not x.ignore, decls )
AttributeError: 'class_t' object has no attribute 'ignore'

> Also I would like to explain them:
> We decided on next concepts, correct me if I wrong:
> 
> declarations tree is used to configure code creators

Exactly.

> code creators tree will be used to configure file writers

Probably. Sort of. I'm not sure. I haven't put that much thought into 
this area yet as I have a configuration that actually works for now. 
It's not ideal, but as it does work, improving it is only of second 
priority for me right now.

>> 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.
> 
> I know, this should be fixed. Can you propose naming scheme for
> pyplusplus code creators
> and declarations wrappers/decorators ?

Well, you could fill in some extra words (such as class_wrapper_t) but 
as Python already organizes code in a hierarchy I guess it would be a 
better idea to use decl_wrapper.class_t explicitly instead of importing 
the classes into the namespace of another module. Then it's also clear 
to the reader which class is being referred to.

> [...] 
> 
> class regex_matcher_t:
>     def __init__( self, regex, function ):
>         self.regex = re.compile( regex )
>         self.function = function
> 
>     def __call__( self, decl ):
>         text = self.function( decl )
>         return bool( self.regex.match( text ) )
> 
> If user want to match not only name but something else by regular expression,
> he should not derive from the class, but rather to write function that
> takes as argument
> declaration and returns some text. I found this approach easier then
> starting to find out class hierarchy.

I cannot comment on that right now, first I need to have a closer look 
on how to use that stuff...

> Matthias, I think you should stop to use latest CVS in production environment,
> until we stabilize interface. That's said.

That's ok. I mean, I do want to be able to take advantage of the latest 
features, so it's ok that this might lead to some inconveniences first. 
And the sooner someone notices bugs, the sooner they can be fixed. :)

- Matthias -