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