Closed ghost closed 8 months ago
Thanks for the feedback; that is a significant effort. Reworking the Objeck to C++ interface will break lots of things.
Thanks for the feedback; that is a significant effort. Reworking the Objeck to C++ interface will break lots of things.
I don't think it will break anything. I think it's just a fancier dynamic loading of shared libraries. The current FFI is not changed.
I disagree, all of the C++ bindings will need to be rewitten. Moreover, many of bindings, such s SDL2, are auto-generated. Rewriting the parsers and retesting the interfaces will impact stability.
I will consider and new C++ binding framework however is at the end of the queue.
I disagree, all of the C++ bindings will need to be rewitten. Moreover, many of bindings, such s SDL2, are auto-generated. Rewriting the parsers and retesting the interfaces will impact stability.
The current FFI is still keep as is. Nothing will need to be rewritten. Nothing will break. What I proposing is adding a new one. Less powerful. But simpler to use. Since you only need to write Objeck code but no C++ code. Something like Pinvoke of .NET. Please note that, for complex libraries, .NET developers still have to use C++/CLI. So, for complex libraries, you still have to use the current FFI of Objeck.
I used to propose something similar, but inspired by JNA/JNR: https://github.com/objeck/objeck-lang/issues/351
It doesn't have to be as sophisticated as Pinvoke. It will not replace the current FFI. Like Pinvoke, it make things easier to deal with simple C libraries. The idea is to write the wrapper entirely in Objeck. No C++ code is needed. For complex C libraries, still need to fallback to the current FFI. It's like C++/CLI on .NET, that is used for complex C libraries. But most of the time, Pinvoke is enough.