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

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

On 3/1/06, Matthias Baas <ba...@ir...> wrote:
> Allen Bierbaum wrote:
> >>> Accepted, but in future we will replace print statemnet with logging
> >>> module
> >>>
> > Sounds good.
>
> Sounds good to me as well.

Done, will check in shortly.

> >>> - Decl Decorator
> >>>
> >>> Not accepted. I created declaration wrapper for every declaration. Se=
e
> >>> 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 think that I did mistake - I did not explain what fundamental changes
I am going to do/did. I am sorry. ( I did not have internet connection
and did not
want to sit doing nothing. )

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

Those decl wrappers should be used as high level interface for user to conf=
igure
code creators. It does not really make the different how it implemented ins=
ide.
In our versions it is possible to say

mb =3D 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.

Also as you can see I did not implemented multi decl wrapper - I don't
know how to
implement it.

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 progr=
ammer
who provide you all functionality you need. Do you agree?

> I agree with Allen, this looks fairly complex.

But here are the list of futures that this will allow us to have:
1. Analysis. Using new model I can add code that will analyze declaration f=
or:
    is exportable and if not why
    is finalizable and if not why

2. Better interface - it is easy for user to see what he can customize.

3. It allowed me, not to introduce new concept - declaration type
flags, but rather
    to use isinstance of Python.

> >>> New classes that derives from declaration_t class.
> >>> Every derived decl_wrapper has relevant properties for customizing co=
de
> >>> creators\module_creator.
> >>>
> >>> All code creators properties it is just an redirection to decl_wrappe=
r
> >>> 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... ;)

:-(. I tested my changes. They should work as is without any changes
from user code.
It seems that I introduce a bug.

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

code creators tree will be used to configure file writers

That is exactly, what I did. In order to introduce, as minimum changes as I=
 can,
I just redirected code_creators properties to declaration properties.

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

Thanks

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

Here what I thought:

Finding declaration by some criteria is very useful functionality for pygcc=
xml.
I adopted Allen idea, also I changed few implementation details.
All code that shows the usage of *matcher could be found in relevant
unit testers.
( variable_matcher_tester.py, namespace_matcher_tester.py, filters_tester.p=
y,
  calldef_tester.py )

Example:

        criteria =3D declarations.variable_matcher_t( name=3D'x',
type=3D'unsigned int' )
        x =3D declarations.matcher.get_single( criteria, self.declarations =
)

        criteria =3D declarations.variable_matcher_t(
            name=3D'::bit_fields::fields_t::x'
            , type=3Ddeclarations.unsigned_int_t()
            , value=3Dx.value
            , header_dir=3Dos.path.dirname(x.location.file_name)
            , header_file=3Dx.location.file_name)

Main differences:
1. Better user interface/implementation:

declaration_matcher_t.__call__ is smart enough to find out whether
user wants to match
by full name or name only.

type could be or string or cpptypes.type_t instance.

As I already said, there is own place where user can go and find out
what criteria
he can use.

Take a look on calldef_matcher_t class. The main difference in implementati=
on is
that I allow user to specify something like this:

void f( int, double );

matcher =3D calldef_matcher_t( arg_types=3D[None, 'double'] )
This means that I want to select all function that have 2 arguments
and their second
type is double.

An other change is in regular expression matcher.
Here is the class:

class regex_matcher_t:
    def __init__( self, regex, function ):
        self.regex =3D re.compile( regex )
        self.function =3D function

    def __call__( self, decl ):
        text =3D self.function( decl )
        return bool( self.regex.match( text ) )

If user want to match not only name but something else by regular expressio=
n,
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.


> 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 think, we don't have to start with rules, but common sense.
Rules will come later.

> 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, I think you should stop to use latest CVS in production environme=
nt,
until we stabilize interface. That's said.

> - Matthias -
>


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