Re: [pygccxml-development] Adding wrappers...

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

Roman Yakovenko wrote:
>> That's already the first problem. Currently, a class either has an
>> entire class wrapper or no wrapper at all. But often it would already be
>> enough to just provide wrappers for individual methods. It wouldn't be
>> necessary to create a new C++ wrapper class for that purpose.
> 
> If I understand you right: function can have wrapper, but it is not
> necessary that the wrapper belongs to the class. 

Exactly. This can be used to add new (Python) methods to a class that 
the corresponding C++ does not have or it can be used to replace 
methods. Currently, I'm using the "backdoor" cdef() decorator for this.

>>> decl_wrappers.class_t we have add_code/add_wrapper_code functionality.
>>> I propose to add similar functionality to decl_wrappers.calldef_t class:  two
>>> properties: replace_code and replace_wrapper_code. module_creator.creator_t
>>> class will check those properties and will create right code creators,
>>> that instead of
>>> generating default code will put user code as is.
>> But if we simply replace code then the new code must implement the
>> functionality of the previous code. But as a user I don't know what code
>> pyplusplus has already added to a wrapper so I can't provide its
>> functionality. And by simply replacing it we ignore the previous code
>> and the result might not work as expected anymore.
>> I think adding user wrapper code must not interfere with previously
>> added code by pyplusplus.
> 
> I have very different opinion. My rule is simple:user knows better that py++.

Oh, I see. But I disagree on this one. I'm using software tools so that 
I don't have to remember every detail myself. And it would be nice if 
the tool could also be used by non-experts.

>> I can add include_t creators to classes? ok, I'll keep that in mind and
>> will try it out eventually...
> 
> It is not implemented yet, I see it as one possible solution.

Ah, ok. But when the code has to be changed anyway I'm in favor of 
adding some sort of "File" objects that each has its own code creator 
tree (as was already brought up somewhen earlier)...
(or a similar, more flexible approach)

- Matthias -