It seems python has broad reach into c++ code.
I assume access is via named objects/classes etc, I think in xml files.
It appears then that refactoring c++ code could break existing python code.
If so, how to determine which c++ code is a dependency of such python code? I think the IDE has no way of knowing.
Python access impact on C++ refactoring
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Posts: 176
- Joined: Wed Mar 09, 2022 3:15 am
- Location: Oz
-
- Posts: 124
- Joined: Wed Jun 19, 2019 7:44 pm
Re: Python access impact on C++ refactoring
In the C++ code that conform the Python interface (usually generated by parsing .xml files), FreeCAD C++ objects are accessed via a pointer. So if you don't change the name of these classes or the signature of the members, it shouldn't affect the Python interface. Of course, in any case, you should check the impact of changes on the original classes in the Python interface.
-
- Posts: 176
- Joined: Wed Mar 09, 2022 3:15 am
- Location: Oz
Re: Python access impact on C++ refactoring
But, But, But... How is possible to refactor c++ code when there are dependencies hidden in xml files? If this is right it is a huge disincentive to improve existing code by refactoring. It simply becomes too difficult. The inevitable result is the code can't benefit from 20 years of advancements in software engineering.marioalexis wrote: ↑Sun May 22, 2022 2:18 pm In the C++ code that conform the Python interface (usually generated by parsing .xml files), FreeCAD C++ objects are accessed via a pointer. So if you don't change the name of these classes or the signature of the members, it shouldn't affect the Python interface. Of course, in any case, you should check the impact of changes on the original classes in the Python interface.
Somebody please tell me this is wrong!
-
- Posts: 124
- Joined: Wed Jun 19, 2019 7:44 pm
Re: Python access impact on C++ refactoring
I may not explain clearly.
In general, the methodology is this:
Suppose you have a C++ class named MyClass developed in the files MyClass.cpp and MyClass.h, and you want to expose it to Python.
From a file MyClassPy.xml (which contains, among other things, the names and documentation of the methods and the information of the C++ class that you want to export to Python), the files MyClassPy.cpp and MyClassPy.h are created in the build directory. These files contain the structures needed to get the Python/C++ interface.
On the other hand, in the source directory, the file MyClassPyImp.cpp must contain the implementation of the functions that you want to expose. This is where you make the calls to the MyClass functions that you want to work with.
Actually, the .xml files only serve to generate a very generic code needed for the interface where only names and certain characteristics of the functions are provided. The implementation itself is found in the file MyClassPyImp.cpp, in the source directory.
In general, the methodology is this:
Suppose you have a C++ class named MyClass developed in the files MyClass.cpp and MyClass.h, and you want to expose it to Python.
From a file MyClassPy.xml (which contains, among other things, the names and documentation of the methods and the information of the C++ class that you want to export to Python), the files MyClassPy.cpp and MyClassPy.h are created in the build directory. These files contain the structures needed to get the Python/C++ interface.
On the other hand, in the source directory, the file MyClassPyImp.cpp must contain the implementation of the functions that you want to expose. This is where you make the calls to the MyClass functions that you want to work with.
Actually, the .xml files only serve to generate a very generic code needed for the interface where only names and certain characteristics of the functions are provided. The implementation itself is found in the file MyClassPyImp.cpp, in the source directory.
Last edited by marioalexis on Wed Jun 01, 2022 10:15 pm, edited 1 time in total.
Re: Python access impact on C++ refactoring
ooh...pretty please update Exposing_Cplusplus_to_Python page
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
-
- Posts: 176
- Joined: Wed Mar 09, 2022 3:15 am
- Location: Oz
Re: Python access impact on C++ refactoring
Actually you are being very helpful.
So during the build MyClassPy.cpp and MyClassPy.h are generated from MyClassPy.xml specification, and become the interface from the python side. These do not reach into cpp codebase, other than via MyClassPyImp.cpp (below).
MyClassPyImp.cpp is the interface between the cpp codebase and the MyClassPy.x files.
Am I right then in saying that refactoring in cpp eg method name change, will likely not immediately break stuff, except that if method names change, that will not propagate to the python side and would be confusing. A call to a method from MyClassPyImp.cpp is about the only clue in an IDE.