Re: [pygccxml-development] How to add a new function to an individual file?

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

Roman Yakovenko wrote:
>> - module_creator/creator.py: Modify creator_t.visit_member_function() so
>> that it adds the appropriate code creator object to the list of
>> associated creators for the current class.
> 
> Yes

Currently, it means I have to insert code like this into 
visit_member_function():

     if maker_cls==code_creators.mem_fun_transformed_t:
         ....

This doesn't feel the "right" way to me, but if it's the recommended way 
(and as long as it works) I won't complain anymore... ;)

>> When the option is turned on that Py++ should always create a wrapper
>> class I also have to modify the following places:
> 
> "Turned on" means: there is at least one FT

That's not what I meant. I meant an option that controls whether the 
presence of function transformers (on non-virtual functions) result in 
the creation of a wrapper class or not. I think that's basically the 
finalize functionality (I started a new thread about this).

>> I think this is rather complex and what I don't like about it is that
>> code that belongs together is scattered over several files (even from
>> different sub-packages).
> 
> I don't think that this code "belongs" together. Think about this:
> creator_t class solves "location" problem - where the generated code
> should be logically
> written, while code creators answer the "what" question - what code
> should be created.

Just to make sure this is not a misunderstanding: I didn't mean that 
everything has to be put into one single class. There may be any number 
of separate classes or functions, each with its own responsibility. But 
it would be great if I could keep those classes together in one file 
because I still think that conceptually, this stuff belongs together 
(even though one part solves the location problem and the other part the 
"what" question, those two parts can only exist together and both is 
required to support transformed member functions).

>> Then it would be nice if it was possible to register functions that are
>> invoked by guess_mem_fun_creator_classes() and that can check if they
>> know how to handle a particular declaration, etc.
>> So all in all, it would be great if everything would be a bit more
>> extensible so that a modification like the one that I'm currently trying
>> to do could even be done externally without having to modify internal
>> Py++ code.
> 
> If you want to extend creator_t you will have to derive from it or to
> modify its
> implementation. This is the right way to do it. 

Deriving from creator_t has a few problems:

- The module builder class instantiates the creator object and it does 
that from the builtin creator_t class, not from any derived class.

- If I wanted to modify the behavior of, say, visit_member_function() I 
would have to replace the entire method. This basically means I would 
have to copy the existing code, paste it into my derived class and do my 
modifications (after I have understood what's going on in that method 
anyway). This is not what I understand by "encapsulation".

- This might just be me, but I would have considered methods like the 
visit_*() methods to be internal methods that are an implementation 
detail of the creator class. So if I have to override those internal 
methods I run the risk that my own script will be broken when used with 
future versions of Py++ where some internal stuff has been changed.


- Matthias -