pygccxml-development

[pygccxml-development] pypp_api review

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

Hi. I did small review to pypp_api.

1. cleanTemplateName this function already exists:
    decl_wrapper/algorithm.py - create_valid_name.
    I think you can use it.

2. I could be wrong, but pyplusplus has now all functionality provided by
    DeclWrapper and MultiDeclWrapper. May be they should be removed?

3. iterdecls - this functionality already exists. Please see
    pygccxml/declarations/algorithm.py function __make_flatten_generator.
    It has all functionality provided by iterdecls. Also I did not use
it because of
    performance, it is slowly then creating a list and then iterating over =
it.
    But I could be wrong.

4. I created 2 new printers: decl_printer_t in pygccxml/declarations packag=
e
    and decl_wrapper_printer_t in pyplusplus/decl_wrappers, that derives fr=
om
    decl_printer_t. As a bonus, decl_wrapper_printer_t prints all
relevant properties from
    declaration wrappper classes.

5. I think that ModuleBuilder interface is a little bit messy. There
are so many properties
   and functions. Some configuration is done using properties, other
using function
   arguments. I am not saying that this is wrong, but rather
confusing. Also I did not
   get the guide-line when and what approach to use.

   I think it would be much better to have 2 configuration properties
on module builder
   1. parser_configuration
   2. code_generator_configuration

   Then could would look like this:
   mb =3D module_builder_t( module_name, files, [optional] parser configura=
tion )
   mb.parser_configuration.defines.append( ... )
   mb.code_generator_configuration.license =3D ...

   This way we could remove some code from module_builder. Interface
and code will
   gain readability.

What do you think?

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

Re: [pygccxml-development] pypp_api review

[Allen B. <al...@vr...>]

The current interface is not polished yet and doesn't even work.  I 
really need answers to the questions posed in the message titled 
"Updated status" from 03/04/2006 07:03 PM on this list.  Please take a 
look at that message so we can start discussing it.

Roman Yakovenko wrote:

>Hi. I did small review to pypp_api.
>
>1. cleanTemplateName this function already exists:
>    decl_wrapper/algorithm.py - create_valid_name.
>    I think you can use it.
>  
>
I will need to look at this again.  I think I had a slight modification, 
but I will check.

>2. I could be wrong, but pyplusplus has now all functionality provided by
>    DeclWrapper and MultiDeclWrapper. May be they should be removed?
>  
>
It was never really my intention to remove these since the idea is that 
DeclWrapper will add an easy to use user-level API for interfacing with 
the decls. (ie. users are not required to use the internal APIs or 
understand anything about pyplusplus)  There are still several things in 
the interface that I can't do with the pyplusplus wrappers (if I could 
get access to them).  (see message above)

>3. iterdecls - this functionality already exists. Please see
>    pygccxml/declarations/algorithm.py function __make_flatten_generator.
>    It has all functionality provided by iterdecls. Also I did not use
>it because of
>    performance, it is slowly then creating a list and then iterating over it.
>    But I could be wrong.
>  
>
I will check into this.  If they are the same I would say I like the 
name iterdecls better at least because it sounds more like something 
that would iterate over a tree of decls.  __make_flatten_generator 
sounds more like something that creates a new list.

>4. I created 2 new printers: decl_printer_t in pygccxml/declarations package
>    and decl_wrapper_printer_t in pyplusplus/decl_wrappers, that derives from
>    decl_printer_t. As a bonus, decl_wrapper_printer_t prints all
>relevant properties from
>    declaration wrappper classes.
>  
>
Does one of these have the modifications that I had in the helper 
printer in the pyppapi?  I had modified that printer to print less a 
less verbose tree in a way that I think would be of help to users trying 
to wrap an API.

>5. I think that ModuleBuilder interface is a little bit messy. There
>are so many properties
>   and functions. Some configuration is done using properties, other
>using function
>   arguments. I am not saying that this is wrong, but rather
>confusing. Also I did not
>   get the guide-line when and what approach to use.
>
>   I think it would be much better to have 2 configuration properties
>on module builder
>   1. parser_configuration
>   2. code_generator_configuration
>
>   Then could would look like this:
>   mb = module_builder_t( module_name, files, [optional] parser configuration )
>   mb.parser_configuration.defines.append( ... )
>   mb.code_generator_configuration.license = ...
>
>   This way we could remove some code from module_builder. Interface
>and code will
>   gain readability.
>
>What do you think?
>  
>
I need to look into this once I can get the code working again.  We also 
need to make a list of all the things that we would want to be able to 
configure and set.  This would help us to understand how it may be best 
presented to a user.

When you refer to module_builder are you talking about some new class 
you have added in pyplusplus?

-Allen

>--
>Roman Yakovenko
>C++ Python language binding
>http://www.language-binding.net/
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
>_______________________________________________
>pygccxml-development mailing list
>pyg...@li...
>https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>
>  
>

Re: [pygccxml-development] pypp_api review

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

On 3/6/06, Allen Bierbaum <al...@vr...> wrote:
> The current interface is not polished yet and doesn't even work.  I
> really need answers to the questions posed in the message titled
> "Updated status" from 03/04/2006 07:03 PM on this list.  Please take a
> look at that message so we can start discussing it.

I'd like, but it seems that I do not have such message. Can you post it aga=
in?

> Roman Yakovenko wrote:
>
> >2. I could be wrong, but pyplusplus has now all functionality provided b=
y
> >    DeclWrapper and MultiDeclWrapper. May be they should be removed?
> >
> >
> It was never really my intention to remove these since the idea is that
> DeclWrapper will add an easy to use user-level API for interfacing with
> the decls. (ie. users are not required to use the internal APIs or
> understand anything about pyplusplus)  There are still several things in
> the interface that I can't do with the pyplusplus wrappers (if I could
> get access to them).  (see message above)

I don't have that message, I could tell more when I read it.

> >3. iterdecls - this functionality already exists. Please see
> >    pygccxml/declarations/algorithm.py function __make_flatten_generator=
.
> >    It has all functionality provided by iterdecls. Also I did not use
> >it because of
> >    performance, it is slowly then creating a list and then iterating ov=
er it.
> >    But I could be wrong.
> >
> >
> I will check into this.  If they are the same I would say I like the
> name iterdecls better at least because it sounds more like something
> that would iterate over a tree of decls.  __make_flatten_generator
> sounds more like something that creates a new list.

I wrote it and tested. I did not like performance, so I rename it to be pri=
vate.
You can rename it to iterdecls.

> >4. I created 2 new printers: decl_printer_t in pygccxml/declarations pac=
kage
> >    and decl_wrapper_printer_t in pyplusplus/decl_wrappers, that derives=
 from
> >    decl_printer_t. As a bonus, decl_wrapper_printer_t prints all
> >relevant properties from
> >    declaration wrappper classes.
> >
> >
> Does one of these have the modifications that I had in the helper
> printer in the pyppapi?  I had modified that printer to print less a
> less verbose tree in a way that I think would be of help to users trying
> to wrap an API.

If not than this is a bug. I left all functionality you created.


> I need to look into this once I can get the code working again.  We also
> need to make a list of all the things that we would want to be able to
> configure and set.  This would help us to understand how it may be best
> presented to a user.

Yes this is what I will try to do this evening.

> When you refer to module_builder are you talking about some new class
> you have added in pyplusplus?

No. I am just switched to pyplusplus coding convention. I refer to the
class that you and
Matthias will create. I am waiting for this. I took a look on the
ModuleBuilder class\module
and moved some functionality to the right place. That's all.


> -Allen


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

Re: [pygccxml-development] pypp_api review

[Allen B. <al...@vr...>]

>>I need to look into this once I can get the code working again.  We also
>>need to make a list of all the things that we would want to be able to
>>configure and set.  This would help us to understand how it may be best
>>presented to a user.
>>    
>>
>
>Yes this is what I will try to do this evening.
>  
>
Could you summary the results and post them on the wiki for discussion?  
I think a good place to start would be the parameters that are currently 
passed to the init() and writeModule() methods of the ModuleBuilder.  
 From there we/I need to look at what configuration options Matthias is 
using and add the unique ones to the list of things to support.  After 
that we can start discussing ideas for new options that may be needed (I 
can already think of a few that would be helpful).

>  
>
>>When you refer to module_builder are you talking about some new class
>>you have added in pyplusplus?
>>    
>>
>
>No. I am just switched to pyplusplus coding convention. I refer to the
>class that you and
>Matthias will create. I am waiting for this. I took a look on the
>ModuleBuilder class\module
>and moved some functionality to the right place. That's all.
>  
>
OK. The "move some functionality to the right place" is the part that 
surprised me.  I think we need to make sure we are all on the same page 
here because right now it seems like you (Roman) are looking to extend 
the internal pyplusplus APIs to not only support the new functionality 
but also looking to have users call to it directly.  My goal at least 
was that users would only need to use the pypp_api and would never need 
to know about or call the internal APIs.  I think Matthais was working 
in a similar direction but we will have to ask him.  We should all make 
sure we are clear on what the goal is we are trying to accomplish so we 
don't end up with duplicated effort and simply a more powerful internal 
api for pyplusplus.

-Allen

Re: [pygccxml-development] pypp_api review

[Allen B. <al...@vr...>]

Allen Bierbaum wrote:

>
>> 5. I think that ModuleBuilder interface is a little bit messy. There
>> are so many properties
>>   and functions. Some configuration is done using properties, other
>> using function
>>   arguments. I am not saying that this is wrong, but rather
>> confusing. Also I did not
>>   get the guide-line when and what approach to use.
>>   I think it would be much better to have 2 configuration properties
>> on module builder
>>   1. parser_configuration
>>   2. code_generator_configuration
>>
>>   Then could would look like this:
>>   mb = module_builder_t( module_name, files, [optional] parser 
>> configuration )
>>   mb.parser_configuration.defines.append( ... )
>>   mb.code_generator_configuration.license = ...
>>
I was thinking about this a little more and took a look at the code.  As 
far as I can tell all configuration is currently done by passing 
parameters to the ModuleBuilder init when things get started up and then 
to the writeModule() method when the user wants to finally generate the 
code.  I don't see anything done directly with properties.  Am I missing 
something here?

Are you just saying that you would like to see the internal properties 
grouped into two namespaces so they are separated for users?  (that 
looks to be what the interface example above would do)

-Allen

Re: [pygccxml-development] pypp_api review

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

On 3/6/06, Allen Bierbaum <al...@vr...> wrote:
> Allen Bierbaum wrote:
>
> >
> >> 5. I think that ModuleBuilder interface is a little bit messy. There
> >> are so many properties
> >>   and functions. Some configuration is done using properties, other
> >> using function
> >>   arguments. I am not saying that this is wrong, but rather
> >> confusing. Also I did not
> >>   get the guide-line when and what approach to use.
> >>   I think it would be much better to have 2 configuration properties
> >> on module builder
> >>   1. parser_configuration
> >>   2. code_generator_configuration
> >>
> >>   Then could would look like this:
> >>   mb =3D module_builder_t( module_name, files, [optional] parser
> >> configuration )
> >>   mb.parser_configuration.defines.append( ... )
> >>   mb.code_generator_configuration.license =3D ...
> >>
> I was thinking about this a little more and took a look at the code.  As
> far as I can tell all configuration is currently done by passing
> parameters to the ModuleBuilder init when things get started up and then
> to the writeModule() method when the user wants to finally generate the
> code.  I don't see anything done directly with properties.  Am I missing
> something here?

I think yes. In order to set licence you need to modify mLicense.

Also why __init__ takes parsing configuration and not parse function
( I think I know the answer, but still )

I think that in __init__, parse or writeModule we should only ask for
parameters we can deal without them. All other should be set using properti=
es.

> Are you just saying that you would like to see the internal properties
> grouped into two namespaces so they are separated for users?  (that
> looks to be what the interface example above would do)

Yes, I fill that this is a little better way - you say to user what
property configure what.
( I hope I said this right :-) )

Don't you think so?

> -Allen


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

Re: [pygccxml-development] pypp_api review

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

>On 3/6/06, Allen Bierbaum <al...@vr...> wrote:
>  
>
>>Allen Bierbaum wrote:
>>
>>    
>>
>>>>5. I think that ModuleBuilder interface is a little bit messy. There
>>>>are so many properties
>>>>  and functions. Some configuration is done using properties, other
>>>>using function
>>>>  arguments. I am not saying that this is wrong, but rather
>>>>confusing. Also I did not
>>>>  get the guide-line when and what approach to use.
>>>>  I think it would be much better to have 2 configuration properties
>>>>on module builder
>>>>  1. parser_configuration
>>>>  2. code_generator_configuration
>>>>
>>>>  Then could would look like this:
>>>>  mb = module_builder_t( module_name, files, [optional] parser
>>>>configuration )
>>>>  mb.parser_configuration.defines.append( ... )
>>>>  mb.code_generator_configuration.license = ...
>>>>
>>>>        
>>>>
>>I was thinking about this a little more and took a look at the code.  As
>>far as I can tell all configuration is currently done by passing
>>parameters to the ModuleBuilder init when things get started up and then
>>to the writeModule() method when the user wants to finally generate the
>>code.  I don't see anything done directly with properties.  Am I missing
>>something here?
>>    
>>
>
>I think yes. In order to set licence you need to modify mLicense.
>
>Also why __init__ takes parsing configuration and not parse function
>( I think I know the answer, but still )
>
>I think that in __init__, parse or writeModule we should only ask for
>parameters we can deal without them. All other should be set using properties.
>
>  
>
>>Are you just saying that you would like to see the internal properties
>>grouped into two namespaces so they are separated for users?  (that
>>looks to be what the interface example above would do)
>>    
>>
>
>Yes, I fill that this is a little better way - you say to user what
>property configure what.
>( I hope I said this right :-) )
>
>Don't you think so?
>  
>
Maybe.  I think it is just a matter of getting the right combination of 
usability and power. 

What I was going for in the current interface was to have reasonable 
defaults and let the user override them by passing their options to the 
initialization and write methods.  This seemed like a simple interface 
because they could just look at the documentation for a couple of 
methods to be able know everything they need to set.

There may be a middle ground here were we could allow the "simple" 
options to be configured when initializing the module and then allow 
advanced users to set attributes of the builder to configure the 
advanced settings.  I would not use properties since what we are talking 
about is really publicly accessible attributes of the builder.

Once I get everything working again I will give this idea a try.

-Allen