-
-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: Make Handle_* classes completely transparent #539
Comments
That would be a huge deal, in terms of elegance of API, which seems obvious. |
Hi together. I have a first semi-working code. Most of the examples already work. What currently does not work are the following issues:
|
@jf--- Okay... Now I managed to solve all the problems! 😄 All examples are now working, meaning I achieved full backwards compatibilty. Compared to the old code, one can now implement much more pythonic code like:
I would create some conda packages, such that you can test it with your code. My adaptions are currently based on pythonocc-core 0.17.2 though. |
The OCCT handle smart pointer API is a C++ specific detail and should not be exposed to Python. Instead it should be completely invisible. I used the std::shared_ptr swig library as a basis for the implementation. To be compatible with most of the "old" code, GetHandle() and GetObject() methods still exist but do nothing except from a deprecation warning. In general, I tried to make sure that the code is backwards compatible as possible. Closes tpaviot#539
The OCCT handle smart pointer API is a C++ specific detail and should not be exposed to Python. Instead it should be completely invisible. I used the std::shared_ptr swig library as a basis for the implementation. To be compatible with most of the "old" code, GetHandle() and GetObject() methods still exist but do nothing except from a deprecation warning. In general, I tried to make sure that the code is backwards compatible as possible. Closes tpaviot#539
The OCCT handle smart pointer API is a C++ specific detail and should not be exposed to Python. Instead it should be completely invisible. I used the std::shared_ptr swig library as a basis for the implementation. To be compatible with most of the "old" code, GetHandle() and GetObject() methods still exist but do nothing except from a deprecation warning. In general, I tried to make sure that the code is backwards compatible as possible. Closes #539
The OCCT handle smart pointer API is a C++ specific detail and should not be exposed to Python. Instead it should be completely invisible. I used the std::shared_ptr swig library as a basis for the implementation. To be compatible with most of the "old" code, GetHandle() and GetObject() methods still exist but do nothing except from a deprecation warning. In general, I tried to make sure that the code is backwards compatible as possible. Closes #539 Updated SWIG files
Using the GetHandle(), GetObject() functions is awkward from a python perspective.
Users should not know the details of reference counted objects, when dealing with pythonocc.
Swig offers typemaps for std::shared_ptr, which wraps them completely transparent. The same can be done for Handle_ classes as well.
Since there is already much code out there, that uses the GetHandle() GetObject() syntax, we don't want to break this code. Therefore, both functions can be added, returning just a self reference and doing no harm.
I created a proof of concept, which shows that this in pricipally possible:
https://github.com/rainman110/swighandles
The file https://github.com/rainman110/swighandles/blob/master/standard.i shows, how easy it would be to wrap the handle classes. The dark magic obviously happens at https://github.com/rainman110/swighandles/blob/master/occ_handle1.i.
Much of the code and ideas are actually borrowed from std_shared_ptr.i from swig!
@jf--- @tpaviot What do you think about this idea?
The text was updated successfully, but these errors were encountered: