3 ms·
Headers are a really bad interface IMHO. Yes there’s tooling, but they require your headers be very very specific. Any deviance can break that tooling, so you’r
by dagmx 3y ago
Headers are a really bad interface IMHO. Yes there’s tooling, but they require your headers be very very specific. Any deviance can break that tooling, so you’re either lucky in what you can bind or are writing to a very strict spec.
Modules on the other hand are more strict and would likely have made the job of writing language bindings easier and more predictable.
I’m not sure I agree with your logic about NumPy etc. You seem to be conflating technology limitations with policy ones. They could most certainly use modules too , since they exist in the compiled space anyway. They won’t because they make certain compiler compatibility guarantees but that’s a conflict of interests not of technical quality.
In general your argument feels a bit “older is better due to legacy support”. That would preclude almost any advancement in the space as well, because any new language feature (even just a keyword) would break all your examples above equally too.
- lelanthran 3y ago> Modules on the other hand are more strict and would likely have made the job of writing language bindings easier and more predictable. There's two ways for tooling like swig to work with modules: 1. Read the compiled module and generate the stubs to call into it. 2. Read the source code for the module and generate the stubs for it. Which of those, do you think, is easier than reading C (not C++) header files?
- dagmx 3y agoReading the module information would be significantly easier. (which is not something swig can do today since swig hasn’t been updated in a while ) Parsing code to define an API is horribly fragile. A single macro or unknown keyword can break it. Hence why you had to specify C not C++ headers. Having a statically defined metadata like C++ modules do would have greatly simplified binding generation