Thread: [pygccxml-development] Adding wrappers...
Brought to you by:
mbaas,
roman_yakovenko
From: Matthias B. <ba...@ir...> - 2006-04-09 15:37:14
|
Hi, this mail is sort of a continuation of the thread "How to manage wrapper classes?"... Meanwhile I have some code that can generate wrapper source code for individual member functions. The question now is how do I insert those into pyplusplus? What I would actually like to do is adding those generated functions to the appropriate *.cpp file that is generated by pyplusplus and then replace the original member function with this wrapper function. I had a look at the multi file writer (while doing so I also added some doc strings) but it seems that adding code to a generated file is not possible. Alternatively, I could stick my new code in a separate file (.h/.cpp). Then the only problem is to include the header in the pyplusplus file. As far as I can tell this also cannot be done on a file-by-file basis, but I could add the header files to *all* generated files at once (not really a nice solution but at least it could work). Are there any suggestions on how this could be improved? I think pyplusplus is in need of more flexibility in this area. This all gets even more problematic if pyplusplus has already decided to generate wrappers and I want to add wrapper code as well. How can these two be combined? It might be that I have such examples as well in the Maya SDK, but I'm not really that far yet... - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-04-09 17:26:58
|
On 4/9/06, Matthias Baas <ba...@ir...> wrote: > Hi, > > this mail is sort of a continuation of the thread "How to manage wrapper > classes?"... Good. I knew that you plan next revolution in py++. Now code_creators are target. Okay, lets do it :-) > Meanwhile I have some code that can generate wrapper source code for > individual member functions. The question now is how do I insert those > into pyplusplus? > What I would actually like to do is adding those generated functions to > the appropriate *.cpp file that is generated by pyplusplus and then > replace the original member function with this wrapper function. It is possible to solve your problem using existing tools + adding some new ones. The general solution is next: every class has associated class wrapper with it. file writers guarantee that class will see definition of it's class wrapper, otherwise it will not compile. O= n decl_wrappers.class_t we have add_code/add_wrapper_code functionality. I propose to add similar functionality to decl_wrappers.calldef_t class: t= wo 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. I think, this is simple solution that is very easy to understand and implem= ent. ( I estimate 2-3 days =3D=3D ( 6 - 8 hours including some testing ) User can use powerful query interface and don't need to be familiar with co= de creators. What do you think? > I had a > look at the multi file writer (while doing so I also added some doc > strings) Many thanks! > but it seems that adding code to a generated file is not possible. You can always to derive from built-in file_writer and implement your own o= ne. This is was my original idea. > Alternatively, I could stick my new code in a separate file (.h/.cpp). > Then the only problem is to include the header in the pyplusplus file. > As far as I can tell this also cannot be done on a file-by-file basis, > but I could add the header files to *all* generated files at once (not > really a nice solution but at least it could work). No, the better solution is to add to code_creators.class_t list of code_creators.include_t. Thus file writer will understand that user provide= d an additional header files and will put them in a right place. > Are there any suggestions on how this could be improved? I think > pyplusplus is in need of more flexibility in this area. I agree :-). You can prepare "to do" list for next release. > This all gets even more problematic if pyplusplus has already decided to > generate wrappers and I want to add wrapper code as well. How can these > two be combined? It might be that I have such examples as well in the > Maya SDK, but I'm not really that far yet... I prefer to solve main problematic scenario. After this we will see. If we will release py++ this week, it is possible to implement all your request next week. We have some holidays ( passover ). > - Matthias - -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-04-11 07:37:06
|
Roman Yakovenko wrote: > Good. I knew that you plan next revolution in py++. Evolution! It's evolution, not Revolution... ;-) > every class has associated class wrapper with it. file writers > guarantee that class > will see definition of it's class wrapper, otherwise it will not compile. On 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. > 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'm currently experimenting with a model that is similar to the existing code creators, sort of special "micro code creators" that together create one wrapper method. I'll post more about that in a separate mail. >> but it seems that adding code to a generated file is not possible. > > You can always to derive from built-in file_writer and implement your own one. > This is was my original idea. I was already toying with that idea but haven't done so yet... >> Alternatively, I could stick my new code in a separate file (.h/.cpp). >> Then the only problem is to include the header in the pyplusplus file. >> As far as I can tell this also cannot be done on a file-by-file basis, >> but I could add the header files to *all* generated files at once (not >> really a nice solution but at least it could work). > > No, the better solution is to add to code_creators.class_t list of > code_creators.include_t. Thus file writer will understand that user provided an > additional header files and will put them in a right place. I can add include_t creators to classes? ok, I'll keep that in mind and will try it out eventually... - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-04-11 07:53:20
|
On 4/11/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > > Good. I knew that you plan next revolution in py++. > > Evolution! It's evolution, not Revolution... ;-) :-) > > every class has associated class wrapper with it. file writers > > guarantee that class > > will see definition of it's class wrapper, otherwise it will not compil= e. On > > 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. May be good idea. I need to check whether= it could be implemented with simple interface. > > 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.creat= or_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+= +. > I'm currently experimenting with a model that is similar to the existing > code creators, sort of special "micro code creators" that together > create one wrapper method. I'll post more about that in a separate mail. Good, I'd like to see it. > >> but it seems that adding code to a generated file is not possible. > > > > You can always to derive from built-in file_writer and implement your o= wn one. > > This is was my original idea. > > I was already toying with that idea but haven't done so yet... It should be simple. > >> Alternatively, I could stick my new code in a separate file (.h/.cpp). > >> Then the only problem is to include the header in the pyplusplus file. > >> As far as I can tell this also cannot be done on a file-by-file basis, > >> but I could add the header files to *all* generated files at once (not > >> really a nice solution but at least it could work). > > > > No, the better solution is to add to code_creators.class_t list of > > code_creators.include_t. Thus file writer will understand that user pro= vided an > > additional header files and will put them in a right place. > > 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. > - Matthias - -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-04-11 12:19:51
|
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 - |