Re: [pygccxml-development] [FT] small issue

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

Roman Yakovenko wrote:
> On 9/25/06, Matthias Baas <ba...@ir...> wrote:
>> Roman Yakovenko wrote:
>> > Because when user will try to add new transformation, he will need to
>> > understand code creators
>>
>> Why do you think this is the case? It's not. If a transformer creates
>> code that requires a particular header, it has to declare so by calling
>> the require_header() method on the corresponding code manager object.
> 
> Why creator_t can not ask the code manager required headers?

It gets those headers via the code creator object.

>> >> So how does the current design deal with the problem that a code 
>> creator
>> >> might generate code that requires a particular header file?
>> >
>> > Very very simple - all this information creator_t takes from
>> > decl_wrappers classes.
>>
>> Could you provide an explanation using the following example scenario:
>>
>> A user implements a custom code creator in his generation script. The
>> code creator can be parameterized and can produce slightly different
>> code depending on those parameters. Each code variation has its own set
>> of required header files, some of which are written by the user, some
>> are part of the project he's creating wrappers for and some might be
>> from the Py++ code repository.
>> After the Py++ code creator tree has been built, the user adds several
>> of his custom creators at appropriate places into the tree.
>>
>> Now the question is, what else has to be done to include the required
>> header files and who's actually including them?
> 
> User should modify the code creators tree and add "include" creators to it.
> Now, how he finds out what "include"s are needed is up to him. He is 
> free to implement this as he wants. 

Before, you said I'm violating the design by adding the 
get_required_headers() method, now you say the design doesn't specify a 
particular way how to obtain header files and I can do it as I want.
Pardon me, but this sounds like a contradiction to me.

Besides that, I regard it as a design flaw that the API doesn't handle 
this properly and that I have to introduce dependencies among seemingly 
unrelated locations in my code. In my opinion, this makes maintenance 
more difficult. I would have preferred a truly object-oriented/modular 
solution where all "information" can be kept in one place and where an 
object can encapsulate all its implementation details.

>> And where do the decl_wrapper classes come into play here?
> 
> decl_wrapper does not come into play here.

Sorry, but that's again a contradiction to what you said above ("all 
this information creator_t takes from decl_wrappers classes.". It's 
still quoted above).

- Matthias -